AM2612: When building the code with -O2, the device will be reboot if flashing the -O2 image

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 */
    
    
    }
    

  • Sorry for my Typo: the SDK they used is this version: C:\ti\mcu_plus_sdk_am261x_11_00_00_29

  • 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 Rio,

    Any response here from customer?

    Regards,
    Shaunak

  • Hi Shaunak,

    Our code is built with -O2(or -Oz). When the code executes "tiesc_memset" (inside "bsp_init / bsp_esc_reg_perm_init"), it triggers a HwiP_data_abort_handler.

  • 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