TMS570LC4357: Missing data when writing more than 3 words over EMIF.

Hello Srihari,

TMS570LC43x device supports data cache. Cache stores most recently used words in small memory to increase the speed in which a data is accessed. Whenever CPU wants to write a word, it checks to see if the address it wants to write the data to, is present in the cache or not. If address is present in the cache and the memory is configured as cache write back, the data is updated only in the cache and updated into the memory in later time. Data is updated in the memory only when the cache line is ready to replaced.

Can you please configure the memory region to cache write through through the MPU configuration? In write through, data is simultaneously updated to cache and memory. This process is simpler and more reliable.

Hi Wang,

Thank you for your reply. 

Initially, we configured MPU as outer and inner non-cacheable which actually disables the cache ( even though enabled cached during the processor initialization). We were expecting data to be written directly to the memory as the cache was disabled but it was not the case

With your suggestion, we tried to configure the memory region to cache write-through, through the MPU configuration but saw the same issue. ( when we send 8 words, we could see only 6 CS and WE).

But analyzing further and going through the document SPNA238 ( see below), we have configured MPU as strongly ordered and could data written to memory without any data loss.

For 8 words write, couls see 8 CS and WE. Even the data was matching.

Also, for the MPU configuration DEVICE SHAREABLE AND DEVICE NON SHARABLE, we could see data written without loss.

Please let us know if this is the correct configuration we can use.

Hi Wang,

As indicated in my previous post, we were able to get the expected CS and WE signal when MPU is configured as Strongly Ordered or Shareable Device for FPGA

On the same EMIF bus, we have external SRAM (CY62167EV30) controlled through CS3 ( FPGA connected on CS2) which is configured as Async with EMIF timings:

When we configured SRAM MPU region starting at 0x64000000 ( FPGA starts at 0x60000000) as 

Outer and Inner Write-Through, no Write-Allocate Normal  or 
Outer and Inner Write-Back, no Write-Allocate Normal or 
Outer and Inner Non-cacheable Normal

we observed similar issues on SRAM which occurred on FPGA interface ie., if we write more than 3 words to a single SRAM address location( for example writing 8 words to address location zero), some data was missed. See the snapshot for below for 8 words write (Yellow is write enable, Green is chip select).

But if we configure as Strongly Ordered or Shareable Device Memory region, we could able to write to SRAM address location without any issues and could see expected CS and WE for the number of writes. (See below)Also, we were able to allocate some variables ( declared as global ) in the SRAM and could access the same.

But if we want to allocate a stack or execute a program from the external SRAM, sometimes getting an exception or source code running from flash not able access the stack.

Any advice or guidance on how to set up the memory region which will enable SRAM to use as a stack and also execute the program.

Hello,

Instructions cannot be executed from regions with Device or Strongly-Ordered memory type attributes. 

Hi Wang,

 As indicated previously, currently we are using Normal Mode only for the EMIF configuration to communicate with the SRAM. And the configured HCLK and GCLK are 60 and 180MHz respectively.

The MPU configurations for SRAM we are using as:

NORMAL_OINC SHARED which is Memory type = Normal Outer and inner cachable and shared
and permission as PRIV_RW_USER_RW_EXEC = read/write in privileged mode, read/write in user mode, and execute

In our application code, the only problem we are seeing is while putting the stack data in the SRAM. If we move the complete stack ( except during initialization) application doesn't run and sometimes could see exceptions. But if allocates variables (mostly global data) it works well.

For the EMIF configurations we are using the same timing which we mentioned in our previous post; we have also tried making the Turn Around time to 1, but the same observations.

One more concern we have is on the issue which we have mentioned in our previous post, we are still facing issue if we are writing data to the same location ( more than 4 words) when we are configuring the MPU as write-through. Please let us know if this is the known issue on the processor or any further configuration we are missing.

Please Help us in resolving this issue.

For the last two screenshots in your first post:

For 16-bit data write, there is only one WE pulse in on CS period since only 1 bus transaction. For 32-bit data write, there are two WE pulses in one CS period because of of two bus transaction. This is normal.

I think you have noticed that the extra duration in nCS waveform after nWE switches to HIGH. 

EMIF asynchronous interface can operate in either normal mode or select strobe mode. In normal mode the nCS will be active for the entire EMIF transaction. In select strobe mode the nCS is only active during the strobe time. This is the basic difference between the two mode.

In normal mode, as mentioned the nCS is active for an entire EMIF bus transaction. For example, if you are writing to a EMIF address, the nCS is active for the entire bus transaction (16-bit write) while the nWE has two or three pulses while the nCS is active. This is the bug in revA silicon. However, in select strobe mode, the nCS is only active during the strobe phase which means that the nCS is actually active in phase with the nWE. While we see extra nWE pulses in normal mode we would also see extra nCS in select strobe mode.

This bug has been fixed in revB silicon. The extra nWE pulses has been removed during write transactions. However, there was some technical difficulty to shorten the extra duration of the active nCS in addition to removing the extra WE pulses. When switched to select strobe mode, these extra duration of nCS remains as two extra nCS pulses. But the nWE and nOE are not active when these extra nCS pulses are active. So from a memory access stand point this should be fine. All writes and reads to the memory should be qualified with the valid nWE and nOE.

For read, not only were we able to remove the extra nOE pulses but also to shorten the nCS as well to improve EMIF performance/bandwidth. Therefore, during read, there is no extra nCS pulses seen in either normal or select strobe mode.

This extra CS duration will lower the throughput, but will not cause the data lost.

Hello Srihari,

Have you solved your EMIF problem: missing data when writing more than 3 words?