Part Number: AM2612
Champs:
My cust tested their binary on their PCB, Am2612 will be reboot if flag with -O2.
Is this a known-issue?
How to fix this?
They are using the SDK:
C:\ti\mcu_plus_sdk_am263px_11_00_00_19
Thanks.
BR Rio
Part Number: AM2612
Champs:
My cust tested their binary on their PCB, Am2612 will be reboot if flag with -O2.
Is this a known-issue?
How to fix this?
They are using the SDK:
C:\ti\mcu_plus_sdk_am263px_11_00_00_19
Thanks.
BR Rio
The attached is the LK cmd file, plz check.
/* 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=32768
-e_vectors /* This is the entry of the application, _vector MUST be placed starting address 0x0 */
/* This is the size of stack when R5 is in IRQ mode
* In NORTOS,
* - Here interrupt nesting is enabled
* - This is the stack used by ISRs registered as type IRQ
* In FreeRTOS,
* - Here interrupt nesting is enabled
* - This is stack that is used initally when a IRQ is received
* - But then the mode is switched to SVC mode and SVC stack is used for all user ISR callbacks
* - Hence in FreeRTOS, IRQ stack size is less and SVC stack size is more
*/
__IRQ_STACK_SIZE = 256;
/* This is the size of stack when R5 is in IRQ mode
* - In both NORTOS and FreeRTOS nesting is disabled for FIQ
*/
__FIQ_STACK_SIZE = 256;
__SVC_STACK_SIZE = 4096; /* This is the size of stack when R5 is in SVC mode */
__ABORT_STACK_SIZE = 256; /* This is the size of stack when R5 is in ABORT mode */
__UNDEFINED_STACK_SIZE = 256; /* This is the size of stack when R5 is in UNDEF mode */
SECTIONS
{
.vectors : {
} > R5F_VECS , palign(8)
GROUP : {
.text.hwi : {
} palign(8)
.text.cache : {
} palign(8)
.text.mpu : {
} palign(8)
.text.boot : {
} palign(8)
.text:abort : {
} palign(8)
} > OCRAM
GROUP : {
.text : {
} palign(8)
.rodata : {
} palign(8)
} > OCRAM
GROUP : {
.data : {
} palign(8)
} > OCRAM
GROUP : {
.bss : {
} palign(8)
RUN_START(__BSS_START)
RUN_END(__BSS_END)
.sysmem : {
} palign(8)
.stack : {
} palign(8)
} > OCRAM
GROUP : {
.irqstack : {
. = . + __IRQ_STACK_SIZE;
} align(8)
RUN_START(__IRQ_STACK_START)
RUN_END(__IRQ_STACK_END)
.fiqstack : {
. = . + __FIQ_STACK_SIZE;
} align(8)
RUN_START(__FIQ_STACK_START)
RUN_END(__FIQ_STACK_END)
.svcstack : {
. = . + __SVC_STACK_SIZE;
} align(8)
RUN_START(__SVC_STACK_START)
RUN_END(__SVC_STACK_END)
.abortstack : {
. = . + __ABORT_STACK_SIZE;
} align(8)
RUN_START(__ABORT_STACK_START)
RUN_END(__ABORT_STACK_END)
.undefinedstack : {
. = . + __UNDEFINED_STACK_SIZE;
} align(8)
RUN_START(__UNDEFINED_STACK_START)
RUN_END(__UNDEFINED_STACK_END)
} > OCRAM
GROUP : {
.ARM.exidx : {
} palign(8)
.init_array : {
} palign(8)
.fini_array : {
} palign(8)
} > OCRAM
.bss.log_shared_mem (NOLOAD) : {
} > LOG_SHM_MEM
.bss.ipc_vring_mem (NOLOAD) : {
} > RTOS_NORTOS_IPC_SHM_MEM
.bss.sipc_hsm_queue_mem (NOLOAD) : {
} > MAILBOX_HSM
.bss.sipc_secure_host_queue_mem (NOLOAD) : {
} > MAILBOX_R5F
GROUP : {
.fixed.fw_version : {
} align(8)
.bss.nocache : {
} align(8)
} > NON_CACHE_MEM
GROUP : {
.tcma_code : {
} align(8)
} > R5F_TCMA
GROUP : {
.fixed.bootloader_shared_data : {
} align(8)
} > Retain_Share_Memory
}
MEMORY
{
R5F_VECS : ORIGIN = 0x0 , LENGTH = 0x40
R5F_TCMA : ORIGIN = 0x40 , LENGTH = 0x7FC0
R5F_TCMB : ORIGIN = 0x80000 , LENGTH = 0x8000
SBL : ORIGIN = 0x70000000 , LENGTH = 0x50000
OCRAM : ORIGIN = 0x70054000 , LENGTH = 0xA7000
NON_CACHE_MEM : ORIGIN = 0x70050000 , LENGTH = 0x4000
Retain_Share_Memory : ORIGIN = 0x7017FFE0 , LENGTH = 0x20
LOG_SHM_MEM : ORIGIN = 0x700FB000 , LENGTH = 0x1000
Share_Memory : ORIGIN = 0x700FC000 , LENGTH = 0x4000
FLASH : ORIGIN = 0x60100000 , LENGTH = 0x80000
RTOS_NORTOS_IPC_SHM_MEM : ORIGIN = 0x72000000 , LENGTH = 0x3E80
MAILBOX_HSM : ORIGIN = 0x44000000 , LENGTH = 0x3CE
MAILBOX_R5F : ORIGIN = 0x44000400 , LENGTH = 0x3CE
/* For memory Regions not defined in this core but shared by other cores with the current core */
}
Hi Rio,
A few questions:
1. Is this SBL being compiled with -O2 or the application? Does the application randomly exit and re-boot and run the SBL? Does it happen after certain "x" seconds/minutes or can randomly occur?
2. Does everything work fine with -O1 flag, can you also try -Os flag?
3. We might not get much information from the linker file, we might need to find the exact cause, like if the application is triggering some major assert or abort
4. Does customer have any watchdog that might trigger a reset?
5. Can the customer try using this API (or read the memory address attached in screenshot):
SOC_RcmResetCause SOC_rcmGetResetCause (SOC_Rcmr5fssNum r5fssNum)
This API/register will give the reset cause, incase the device is getting reset due to some reason, it will tell the cause

Regards,
Shaunak
Hi Willie,
tiesc_memset is not a function used in SDK. We might need some files from your application which use this function. What i believe is happening here is that the compiler is trying to optimize and re-arranging some stuff, causing abort.
We might need a code review. Can you please share the files which call the "bsp_init/ bsp_esc_reg_perm_init" functions? Can you also share your .map file?
Regards,
Shaunak
Responded over email, please test if the provided solution works
Regards,
Shaunak
Hi Shaunak:
Appreciated your help, your solution works, I will close this ticket.
BR Rio