Activity
From 06/19/2016 to 07/18/2016
07/12/2016
- JC 09:02 AM Software Development: RE: SPI1 controller, access to FLASH and carrier board. NOT linux based.
- Excellent glad you got it working.
- IS 12:16 AM Software Development: RE: SPI1 controller, access to FLASH and carrier board. NOT linux based.
- Johnathan,
Joy Joy, Happy Happy.
Everything is working. There were three items altogether. First was the "open drain" on the chip select. The EE added a pull up resistor and that worked). We were able to finally capture the spi si...
07/11/2016
- FW 05:06 PM Software Development: RE: L138 dsplink problem - schedule while atomic bug
- I looked deeper into the error we were provoking on our bench; it turned out to be a c++ vector de-referencing error that was causing an invalid page fault. The error message posted above appears to be secondary fallout. I'm thinking tha...
07/09/2016
- JC 06:24 PM Software Development: RE: SPI1 controller, access to FLASH and carrier board. NOT linux based.
- Ian St. John wrote:
> Can you confirm that the signal marked as 'reserved' just beside the SPI1_CSC1 is the SPI1_CSC0 and would that show the chip select operation from reading the flash? It seems a good inference but it is speculative ... - IS 05:56 PM Software Development: RE: SPI1 controller, access to FLASH and carrier board. NOT linux based.
- Hmm. I asked the EE about the diagram and he was interested in the fact that there was a pull up on the CS line. Apparently, none of our documents state that the SPI1_SCS[1] is "open drain".
We have
"am1808 tech ref (spruh82a)".pdf... - IS 12:40 AM Software Development: RE: SPI1 controller, access to FLASH and carrier board. NOT linux based.
- The eeprom is on the i2c0 bus. I'm assuming you are talking about the SPI Nor flash which is on SPI1_CS0.+
Oops. Sorry, I said eeprom when I meant the 8MB flash. The JEDEC result is from FLASH, so ok. I modified the code to do the ... - MW 01:23 PM Software Development: RE: L138 dsplink problem - schedule while atomic bug
- Hi Fred,
Syslink is newer than DSPlink, though in the context of the L138 it's very similar code (syslink evolved from DSPlink).
I am curious about the "sudden" appearance of the error following a power cycle on your fielded unit. ... - FW 12:11 PM Software Development: RE: L138 dsplink problem - schedule while atomic bug
- The error collected above was on the bench after making some minor software changes seemingly unrelated with the code that accesses dsp-link; the one below was just found in the field. The field device was in operation for 2 months with ...
- FW 11:23 AM Software Development: RE: L138 dsplink problem - schedule while atomic bug
- I found the following on the TI site; looks like they struggled with this issue with sys-link... I'm not sure how sys-link is related to dsp-link (newer, older, ?)...
[[https://e2e.ti.com/support/embedded/tirtos/f/355/t/385081]]
07/08/2016
- I think there may be a bug in the dsplink kernel code that causes the scheduler to run after a call to spinlock. "remove_wait_queue" seems to be in atomic code, and anything that can cause a call to the scheduler is not allowed after a s...
- JC 09:33 AM Software Development: RE: SPI1 controller, access to FLASH and carrier board. NOT linux based.
- Ian St. John wrote:
> I am building and programming a custom board without Linux. Basic embedded drivers running from SPI1,CS0 (8MB NOR Flash).
> ...
The eeprom is on the i2c0 bus. I'm assuming you are talking about the SPI Nor flash...
07/05/2016
- I am building and programming a custom board without Linux. Basic embedded drivers running from SPI1,CS0 (8MB NOR Flash).
CCS version 6.1.3, compiler TI 15.15.1 LTS, custom carrier board with 1808-FX-225-RC (MityARM 1808) SOM.
I can ...
06/22/2016
- PB 04:13 AM Software Development: RE: kernel 3.2 - tcpip stack latency
- Hi Greg,
Than you for your feedback.
Indeed, flag CONFIG_PREEMPT is set in kernel config. As far as we can see, there is no issue on the thread itself.
We use VLAN tag to route the traffic specifically from the devices to our c...
06/21/2016
- GG 01:30 PM Software Development: RE: kernel 3.2 - tcpip stack latency
- Hi Patrice,
Since you are using SCHED_RR I am assuming you are using CONFIG_PREEMPT in your kernel config, correct?
Does your design have any sort of network traffic shaping or advanced traffic control in place? I do not think an... - Hello,
We've built an application receiving messages from two devices at a rate of 1 message of 1440 bytes every 10 ms in a thread schedule in SCHED_RR priority 70. This is the higher priority user thread in the system.
A network tra...