This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
As soon as the .text section gets bigger than 0x101E0 file loader verification for the M4F fails with error message
BLAZAR_Cortex_M4F_0: File Loader: Verification failed: Values at address 0x000101E0 do not match Please verify target memory and memory map.
BLAZAR_Cortex_M4F_0: GEL: File: C:\MA\HKCLR_Driver\Firmware\CCS_Workspace\hkdriver_diagnostics\hkdriver_diagnostics_m4fss0-0\Debug\hkdriver_diagnostics_m4fss0-0.out: a data verification error occurred, file load failed.
The linker.cmd is the standard one used is all the sdk examples.
M4F_VECS : ORIGIN = 0x00000000 , LENGTH = 0x00000200
M4F_IRAM : ORIGIN = 0x00000200 , LENGTH = 0x0002FE00
M4F_DRAM : ORIGIN = 0x00030000 , LENGTH = 0x00010000
There seems to be a workaround where one disables verification on load....
Any updates the root cause and fix for this?
Hi Traveler,
The only thing I can think of the total program size (data and code) is bigger than 256KB (the internal memory for M4F), then some of the data or code has to be placed in external memory and the RAT has to be set properly (RAT in example.syscfg).
Can you share your MAP file for your program?
Best regards,
Ming
Hi Traveler,
The other thing is how do you initialize your SoC? laod_dmsc.js or using the SBL_NULL (in the OSPI flash)?
We prefer the SBL_NULL. Please refer to AM243x MCU+ SDK: EVM Setup (ti.com) for details.
Best regards,
Ming
There are a few posts that appear to be this issue. Some are user side memory config issues or operator error. But some seem to be caused by a problem with CCS stuff. https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1230161/tmds64evm-data-verification-error-m4f/4723359 for instance that end with "we'll ask the expert" and then no further response. This is why I'm asking for an update.
The only difference between what works and what does not in my case, in the map file there are entries in the .text section that cross address 0x101E0.
RAT:
addr_translate1.$name = "CONFIG_ADDR_TRANSLATE_REGION0";
addr_translate1.localAddr = 0x80000000;
addr_translate2.$name = "CONFIG_ADDR_TRANSLATE_REGION1";
addr_translate2.systemAddr = 0x20000000;
addr_translate2.localAddr = 0xA0000000;
addr_translate3.$name = "CONFIG_ADDR_TRANSLATE_REGION2";
addr_translate3.systemAddr = 0x40000000;
addr_translate3.localAddr = 0xC0000000;
addr_translate4.$name = "CONFIG_ADDR_TRANSLATE_REGION3";
addr_translate4.systemAddr = 0x60000000;
addr_translate4.localAddr = 0x60000000;
debug_log.enableCssLog = false;
debug_log.enableSharedMemLog = true;
mpu_armv71.$name = "CONFIG_MPU_REGION0";
mpu_armv71.attributes = "Device";
mpu_armv71.allowExecute = false;
mpu_armv72.$name = "CONFIG_MPU_REGION1";
mpu_armv72.size = 18;
MAP: Below is the diff between a map file that works and a map file that does not.
Initialization is via SBL_OSPI lightly customized for my board (changed UART lines) + a diagnostics program that checks board status. I'm jtag resetting and loading over the top of that. As it's the diagnostics I'm currently developing, the RAT/MPU should be the same.
Loading with verification disabled works fine.
Hi Traveler,
It sounds like a known issue. We will investigate it further. Meanwhile, please continue to use disabling the data verification for program loading.
Best regards,
Ming