EMIF 16-bit async. write generates multiple writes

Hi Zhaohong,

I am facing the same issue as Mikael. I'm using a TMS570 MCU to read and write registers of an external asynchronous memory. I have changed the R4 MPU configuration for the EMIF region to "device_shareable". However, I am still having this problem of 2/3 writings instead of only one writing. I am using the version 04.05.02 of HalCoGen. Would you have some idea ?
Thanks
Adrien

Adrien,

  Can you first confirm which TMS570 device you are using? 

 Please refer to the below errata. The silicon is fixed for this errata in the latest silicon revision if you are using TMS570LS31x/TMS570LS12x. Can you try changing to strongly-order and do you still see extra nWE pulses?

If you have the TMS570LC43x device then you will have a different EMIF errata. See below. The latest silicon (revB) is also fixed for this issue. You will need to use the nDQM as a qualifier to suppress the extra WE pulses.

There is some problem when I upload the errata image. For LS31x/LS12x the errata is as follows.

I need to make one correction. The extra WE pulses on LS31x/LS12x was NOT fixed in the latest silicon. The extra WE pulses on LC43x was fixed in the latest silicon.

Hi Charles,

Thanks for your reply.

I am using the device TMS570LS31x. I have tried to change the external memory region (5th region in the R4 MPU/PMU in HalCoGen) to "device shareable" or "strongly ordered", but in both cases it doesn't work, I still have these extra nWE pulses. For the LC43x errata that you sent to me, it is said that the nWE signal could be "externally gated with the DQM signals to suppress the extra WE pulses". Would it be possible for the TMS570LS31x as well ?

Adrien

Hi all,

Sorry to interfere into your discussion but i'm working exactly on this subject for TMS570LC4357 REV B mask

for which this problem is normally solved (errata #39 is claimed to be corrected in the new mask release for this

processor). What we have found with LC4357 dev kit fitted with a Rev B mask (chip is marked "TMP570 4357BZW")

is that there is no more problem for read operation (no extra pulse, the CS signal lasts the programmed time, only one

pulse when doing a read of 16 bits with bus set to 16 bits wide).

But for write operations, the problem of multiple WE pulses (3 pluses) when doing a simple 16 bit write to EMIF bus

still remain present, whatever the memory type is set into R5 core. We tried "NORMAL", then "DEVICE" then

"STRONGLY ORDERED" but the obtained timing is still the same : always 3 WE pulse even if we do a write of

8 bit or 16 bits value (with EMIF width set to 16 bits) for which we expect only one pulse.

This problem on write cycles leads to divide EMIF performance by a factor of 3
since for a simple 16 bits write, it takes 3 basic cycles instead of one.
For instantaneous write performance, it's a problem in our real time application.

Best regards

Sylvain Balssa

HI Sylvain,
Could you please open a new thread and could you upload a screenshot of the WE pulses from your scope capture? Thanks.

Also please send ALL of the MPU region settings. 

The MPU regions can overlap and if they do the region with the HIGHER number takes priority over the region with the lower number. 

So even if you have region #5 setup correctly - it might be overridden by the settings of region 6,7,8....

Hi Anthony,

I have tried different MPU region settings but it doesn't change anything. I've ended up unchecking all the "Enable MPU Region" from the 1st one to the last one (the 12th), but the extra nWE pulses are still there. Therefore, it doesn't seem to be a problem of 5th region being overridden by the other ones.
Actually, I have two writings instead of just one. For instance, when I write a simple 16 bits word at address "0006" of external asynchronous memory region (0x60000000), the TMS first writes an other 16 bits word at address "0005", and then it writes the good 16 bits word at address "0006". So it seems that the TMS automatically writes an other word at the address next to the good one and then writes correctly at the good address. Do you think that this extra writing at the address next to the good one could be caused by an other setting in HalCoGen ? Or even a setting in Code Composer Studio ?

Best Regards,

Adrien

Adrien,

That sounds like a 32-bit write to a 16-bit EMIF.

What is the instruction that causes the write. Is it STR or STRH?

BTW - did you ever confirm your silicon revision ?

-Anthony

Hi Anthony,

Thanks for your reply.
You're right, the word I am writing to the 16-bit EMIF is a 32-bit write, I can see that when I point the mouse over the word while the debug is running. But I don't understand why the word I am writing is a 32-bit word, I think it should be a 16-bit word given the instructions that cause the write. Here is my code below:

#define ASYNCH_BASE_ADDRESS 0x60000000
#define ASYNCH_Short_DataPointer ((volatile unsigned short *)(ASYNCH_BASE_ADDRESS))

void main(void)
{

*(ASYNCH_Short_DataPointer + 6) = (unsigned short) 0xCAFE;


I am probably missing something at some point because the word "0xCAFE" appears to be a 32-bit word in debug mode.

As for the silicon revision, it's the revision D.

Best Regards,

Adrien

The arithmetic operation may be overriding the type qualifier. Try the following, I couldn't test it!

#define ASYNCH_BASE_ADDRESS 0x60000000
#define ASYNCH_Short_DataPointer ((volatile unsigned short *)(ASYNCH_BASE_ADDRESS))

 ASYNCH_Short_DataPointer[6] = 0xCAFE;

OR

#define ASYNCH_DATA_PTR_OFFS(x)  ((volatile unsigned short *)(ASYNCH_BASE_ADDRESS+x))
 
*ASYNCH_DATA_PTR_OFFS(6) = 0xD00D;

Hi Sylvain and Charles,

Can you give the link to the aforementioned thread ?

I'm very nervous about performance to SDRAM access because I spend a lot of time designing a HW config for a computational intensive app.

Thanks for your response

Marc METZGER

Hi Sylvain and Charles,

Can you give the link to the aforementioned thread ?

I'm very nervous about performance to SDRAM access because I spend a lot of time designing a HW config for a computational intensive app.

Thanks for your response

Marc METZGER

Hi Marc,

  The follow-up thread by Sylvain can be found at below link for the LC4357 device. Are you using the same device?

Marc,
Please also note that the issue concerned by Sylvain is SRAM interface related, not SDRAM interface.

Thanks Charles.

Yes I'm using the same device.