TMS570LC4357: TMS570LC4357

Hi Christian,
Apologies for the delayed response!

Christian Karl said:

So, the instruction changed from 0xE92D4010 to 0xF92D4010.

Is it possible to verify the same instruction in flash? I mean i want to know whether it is corrupted during copying into RAM or it is just corrupted in flash itself?

And also disable cache and see the behavior for 0x57ac? Any change in the behavior?

We also have one internal AI which will analyze all our old threads and will provide suggestions, here are some of the suggestions from it for your thread:

The issue you're experiencing appears to be related to several potential factors when executing code from RAM with cache enabled on the TMS570LC4357. Here's my analysis:

1. Memory Corruption Issue:

• The instruction corruption you're seeing (0xE92D4010 becoming 0xF92D4010) suggests a potential cache/memory synchronization issue or memory corruption during the code copy process.
• The fact that it works with smaller code size (0x3504 bytes) but fails with larger size (0x57ac bytes) indicates a possible boundary or alignment issue.

2. MPU Configuration:

• While your MPU region 3 settings appear correct for the address range, there might be overlapping MPU regions that could affect the execution (4).
• When MPU regions overlap, the attributes of the higher-numbered region take precedence (4).

3. Cache Considerations:

• Since you mentioned cache is enabled, there might be cache coherency issues when copying code to RAM and executing it.
• The cache might need to be properly invalidated after copying code to RAM and before execution.

Recommendations:

1. Cache Management:

   • Ensure proper cache invalidation after copying code to RAM
   • Consider adding cache synchronization barriers after the code copy
   • You might need to flush and invalidate both instruction and data caches

2. Memory Alignment:

   • Ensure the RAM destination address is properly aligned for code execution
   • Verify that the copy operation maintains proper alignment throughout

3. MPU Configuration:

   • Double-check all MPU region settings that might overlap with your RAM execution area
   • Ensure the RAM region has proper execute permissions and cache attributes set

4. Code Size Workaround:

   • Since it works with smaller code size, consider splitting the functionality into smaller chunks if possible
   • You might need to add additional cache management operations when dealing with larger code sections

--
Thanks & regards,
Jagadish.

Hi Jagadish,

thanks for your time and answer!

jagadish gundavarapu said:

Is it possible to verify the same instruction in flash? I mean i want to know whether it is corrupted during copying into RAM or it is just corrupted in flash itself?

Here is the function in RAM with the first wrong instruction 0xF92D4010

And here is the function in FLASH:

The function is completely the same. So, the error did not happen during runtime but during compilation/linking?

jagadish gundavarapu said:

And also disable cache and see the behavior for 0x57ac? Any change in the behavior?

When disabling the cache, this one function seems to be correct:

The first instruction is not undefined anymore, but somehow it changed from 0xE92D4010 to 0xE82D4010.

But I found another function which was copied from FLASH to RAM where an instruction is undefined:

This instruction is also wrong in FLASH.

I think disabling the cache brings no changes to this problem.

The main question is, why is it also wrong in FLASH?

Thank you again for your help

Christian

Hi Christian,

Apologies for the delayed response:

The issue you're experiencing with code execution in RAM appears to be related to several factors:

1. Cache and Memory Configuration:

• You have cache enabled and are executing code from RAM
• The instruction corruption (0xE92D4010 becoming 0xF92D4010) suggests a potential cache coherency or memory access issue

2. Size Dependency:

• The code works with smaller sizes (0x3504 bytes) but fails with larger sizes (0x57ac bytes)
• The memory range (0x806d4e0 to 0x8072C8C) is within MPU region 3

Here are the likely causes and recommendations:

1. MPU Configuration:

• Ensure that the RAM region where you're executing code has the correct MPU attributes:
  • Execute permissions must be enabled
  • Proper cache attributes must be set
• When memory regions overlap, the highest numbered region takes precedence

2. Cache Management:

• Before executing code from RAM, ensure proper cache management:
  • Clean and invalidate the data cache for the RAM region where code is copied
  • Invalidate the instruction cache after copying code to RAM
  • Consider using memory barriers after copying code

3. Memory Attributes:

• For RAM regions executing code, consider using:
  • NORMAL_OIWTNOWA_SHARE (Write-Through) instead of Write-Back cache policy
  • Or NORMAL_OINC_SHARE (Non-cacheable) for more deterministic behavior

Verify MPU settings for the RAM region:

// Example MPU configuration for RAM execution
MPU_Region[3].BaseAddress = 0x806d4e0;
MPU_Region[3].Size = MPU_SIZE_32KB | MPU_REGION_ENABLE;
MPU_Region[3].Attributes = MPU_PRIV_RW_USER_RW_EXEC | MPU_NORMAL_OIWTNOWA_SHARE;

Add cache management operations:

// After copying code to RAM
cleanDCache(); // Clean data cache
invalidateICache(); // Invalidate instruction cache
dataMemoryBarrier(); // Ensure all memory operations complete
instructionSynchronizationBarrier(); // Synchronize contex

If problems persist with larger code sizes, consider:

• Breaking the code into smaller sections
• Using non-cacheable memory attributes for the execution region
• Implementing additional memory barriers between sections

--
Thanks & regards,
Jagadish.