TMS570LC4357 RAM & CPU Reset

The RAM is not cleared automatically by reset. Could your code be executing _memInit_()? The HALCoGEn startup code skips calling _meminit_() after a CPU reset.

Hi Bob,

If I step through my code.
I have a valid value in Ram.
I toggle CPURSTCR bit
The debugger then stops at
resetEntry
b _c_int00
At which point the RAM has been cleared to 0.

So its as though the Hardware has reset the RAM before the HALCoGen code is even called?

OK, I just did the same thing with the BLINKY code on a TMS570LC4357, but the RAM was not cleared. This probably has to due with cache settings. Are you using cache as "write back"? (This is the standard way HALCoGen sets up the cache.) If the cache line is not flushed before you do the CPU reset, the data in RAM was only in the cache and never got written to the RAM. Options would be to flush the cache before doing the CPU reset or using "write through".

I'm using cache enabled in the application as I need the performance (I have cache disabled in the bootloader else I cannot get the F021 API to copy to RAM so I can write to the same Flash bank.)

Is there an easy way to flush the cache?

Hi Bob,

That appears to work thank you.
How much affect does Write Through have on performance compared to Write back? Is there a document that details the information on each of the MPU settings other than the TRM?

If there is an large impact on performance then I might need to create separate RAM write through and write back regions in the MPU for the persistent data.

Thanks,
Stu

According to ARM, while it is system dependent, you are not likely to see a noticeable degradation using write through. The Cortex R5 uses a 4 slot buffer to avoid stalling the CPU on RAM write through.

Stu,

This is also going to vary with the latency to access the memory that is being cached.
You may get a small difference if operating on the L2SRAM but a much bigger difference if the RAM being cached is external SDRAM.

It's too hard to predict this - no simple 'forumla' but please look at the events you can measure using the PMU event counters.
I don't see a 'perfect' event for this case because I think you want something like # of cycles stalled because of a write-through.
But you can count how many of these events there are in your code at least and try to determine from this how efficiently you are using the CPU with various configurations of MPU settings. See Table 6-1 Event bus interface bit functions of the Cortex R5 TRM.
We didn't write this (it's an ARM document) so for some of the events described it may be necessary to get clarification from ARM.
But there's a lot you can measure there if you want to. And HalCoGen provides you with APIs and graphical configuration to set up the event counters for all these events.

Thank you for the detailed answer Anthony, this will help me evaluating the performance impact.

Best regards,
Stu