I've had this problem for a while, and discussed it on these forums, but no one has been able to provide any insight yet.
In a nutshell, the M4 core doesn't execute reliably. It will build, but there's something misaligned in memory during the build process. For the past year working on this project, one of the C files requires some number of no-op lines of code added/removed in order to get the M4 code to execute, I assume by creating an offset, otherwise, the core will hard fault after the execution continues from the main breakpoint. It's a matter of trial and error to add/remove no-op lines and see if the code will finally execute or not. The problem could be triggered simply by changing the value of a variable to be set at runtime, even if no new lines are added.
The same code runs fine on other cores.
Today I've started getting a related but different error while working on a different file to the one above. It produces the following error, and while I haven't been able to make it go away by adding no-op code, I have been able to keep it at bay by adding/removing references to unrelated variables in existing DebugP_log calls.
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: M4_Governor.out: a data verification error occurred, file load failed.
Here's a copy of the linker.cmd file:
/* make sure below retain is there in your linker command file, it keeps the vector table in the final binary */
--retain="*(.vectors)"
/* This is the stack that is used by code running within main()
* In case of NORTOS,
* - This means all the code outside of ISR uses this stack
* In case of FreeRTOS
* - This means all the code until vTaskStartScheduler() is called in main()
* uses this stack.
* - After vTaskStartScheduler() each task created in FreeRTOS has its own stack
*/
--stack_size=32768
/* This is the heap size for malloc() API in NORTOS and FreeRTOS
* This is also the heap used by pvPortMalloc in FreeRTOS
*/
--heap_size=49152
SECTIONS
{
/* This has the M4F entry point and vector table, this MUST be at 0x0 */
.vectors:{} palign(8) > M4F_VECS
.text: {} palign(8) > M4F_IRAM /* This is where code resides */
.bss: {} palign(8) > M4F_DRAM /* This is where uninitialized globals go */
RUN_START(__BSS_START)
RUN_END(__BSS_END)
.data: {} palign(8) > M4F_DRAM /* This is where initialized globals and static go */
.rodata: {} palign(8) > M4F_DRAM /* This is where const's go */
.sysmem: {} palign(8) > M4F_IRAM /* This is where the malloc heap goes */
.stack: {} palign(8) > M4F_IRAM /* This is where the main() stack goes */
/* Sections needed for C++ projects */
.ARM.exidx: {} palign(8) > M4F_IRAM /* Needed for C++ exception handling */
.init_array: {} palign(8) > M4F_IRAM /* Contains function pointers called before main */
.fini_array: {} palign(8) > M4F_IRAM /* Contains function pointers called after main */
/* General purpose user shared memory */
.bss.user_shared_mem (NOLOAD) : {} > USER_SHM_MEM
/* this is used when Debug log's to shared memory are enabled, else this is not used */
//.bss.log_shared_mem (NOLOAD) : {} > LOG_SHM_MEM
/* this is used only when IPC RPMessage is enabled, else this is not used */
//.bss.ipc_vring_mem (NOLOAD) : {} > IPC_VRING_MEM
}
MEMORY
{
M4F_VECS : ORIGIN = 0x00000000 , LENGTH = 0x00000200
M4F_IRAM : ORIGIN = 0x00000200 , LENGTH = 0x0002FE00
M4F_DRAM : ORIGIN = 0x00030000 , LENGTH = 0x00010000
/* shared memories that are used by all cores */
/* On M4F,
* - By default MSMC RAM is not accessible to M4F, a RAT entry is needed to make it
* accessible on M4F
* - So make sure there is a RAT entry which has a 1:1 mapping from 0x70000000 to 0x70200000
*/
USER_SHM_MEM : ORIGIN = 0x701D0000, LENGTH = 0x00010000
//LOG_SHM_MEM : ORIGIN = 0x701D0000 + 0x180, LENGTH = 0x00004000 - 0x180
//IPC_VRING_MEM: ORIGIN = 0x701D4000, LENGTH = 0x0000C000
}
This is a very frustrating way to work, so any insight would be greatly appreciated.
