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.

Compiler/F28M35H52C: Bootloader works ONLY during debugging

Part Number: F28M35H52C


Tool/software: TI C/C++ Compiler

Hello,

I am working on a boot-loader for my F28.

Basically, and based to other ticket on this forum, I have two applications, A and B. A needs to jump to B.

A and B are complete separated CCS project. Linker cmd files separate clearly memory area, and B FLASH sections is (RX) from the A.cmd file. I checked also with a readelf that every symbol from B where properly placed in the correct flash range.

The code to jump from A to B is :

#define C_INT00 0x23A9ED // based on "readelf -s -W B.out | grep _c_int00" 
void JumpFromAToB(void)
{
    uint32_t jump_addr = C_INT00;
    jump_addr |= 0x1;
    LOG_STATUS("entry_addr : 0x%08x\n", jump_addr); ((void (*)(void))jump_addr)(); }

When I reboot the board, NOTHING happened. Meaning that I do not have any output on console after the log (which seems correct).

So, I tried to debug this jump to see what happened internally, or at least trying to get some info, and then IT IS WORKING ! Or at least I have some code which is executed from the B part (It seems that I have issues with some drivers).

What can I do to analyze a bit further the situation ?
It seems that bootload is not so used with a F28, does anyone have an example or something functional to analyze ?

Anyone could help on this ?

BR,

T.

  • T,
    I don't think there is anything wrong with the jump/branch code you put. As long as you have the address of entry point of B correct, took care of watch dog (probably disable) before branching to B (let B re-enable watchDOG after it is ready atleast during debug) and made sure there is really valid code that belongs to B at the entry point and beyond things should work.

    If it is not, I'm suspecting that some of the contents of RAM/Flash that are needed by B are not present (over written) by A. You can check this by doing below.

    1.> B on its own should be loadable and executable from CCS. First make sure your debugger run time settings aren't set to run to main() on program load. This helps by halting the program counter at C_int00 after the program load.

    2.> After you load B() the program control should be now at B's C_int00. Now Take a memory dump of entire RAM and flash and save the logs.
    3.> RUN B() and make sure everything is good.

    Now do your normal procedure you do with A() and B() and just after the branch to C_int00 of B() from A(), take the memory dumps of RAM and Flash and compare them with earlier memory logs. All the RAM and Flash needed by B (you can check this from the MAP file of B) should be same as it was when you were running B all by itself.

    Hope this helps and let me know how it goes.

    Best regards
    Santosh Athuru
  • Santosh,

    Thank you for your support ! Good idea, I will try this tomorrow morning (in 15h).

    Your idea point out another things which could maybe be the issue.

    How have to be the loading model on the B() side ?

    Do I have to set something particular in the cmd file as the application B will NOT be executed straight forward after the bootrom ?

    I found this from TI documentation explaining how entry point is going and it seems that something is different using a debugger compare to jump to _c_int00 ?

    Again, thanks you for your help, I will be back soon with the dumps comparison results.

    BR,

    T.

  • T,
    you are right, B is not the application that will be started by boot ROM, so the entry point of B will not match the flash entry point of boot ROM. But that is ok, because you are loading the program B from CCS and CCS at the end of loading should put the program control at the program's entry point.

    I believe you are using the ROM model as explained in section 3.3.2 of the link you attached.


    Best regards
    Santosh Athuru
  • Santosh,

    You are right, ROM model is selected for both A and B (and I try RAM to check but nothing is different).

    Anyway, I have done what you recommend, and here is what I see :

    • Flash is rigorously the same for both, which seems normal.
    • RAM seems not.

    With debuguer, RAM is zeroed before _c_int00. I am not sure of that with the A to B test. Technically I was not able to stop the debuguer just after the jump from the B (even by doing "Assembly step"), so I am not completely sure that RAM is not. But I save memory just before jump (blx assembly step) and after (assembly step + suspend, but I see in my console than scheduler is started...)

    You can find enclosed the RAM saved file, in case of.

    AtoBBeforeBLX_RAM.dat

    AtoB_RAM.dat

    DebuguerB_RAM.dat

    Again, I am not sure to understand the RAM/ROM model differences. For me the B application is not started by the bootrom as usually... Meanings that I am not sure of what is done in the bootrom, so it's hard for me to compare that to what happened in my A to B switch. What rings my bell is the following, in the B build/configPkg/linker.cmd (auto generated) I have that :

    -u _ti_catalog_arm_cortexm3_concertoInit_Boot_entry
    SECTIONS {
        .ti_catalog_arm_cortexm3_concertoInit_flashfuncs  : LOAD = FLASH,
                                                            RUN = C03SRAM,
                                                            table(BINIT)
    }

    Technically I redefined this in my own cmd file and select my own memory. I tried to redefined the table(BINIT) to table(CINIT) to see if it changed something but it does not build.

    Any other idea ?
    Do you have by any chance a minimal example of this kind of switch with this processor ?

    Thanks again for your help,

    BR,

    T.

  • T,
    details about ROM vs RAM model can be found in compiler and assembler tools documentation. This has nothing to do with boot ROM calling the application but has to do with how sections are linked.

    You should be able to set a HW break point at the entry point of B, but usually if you have both A and B loaded in flash, then you can set a HW break point at the entry point of B and run A and hit the break point.

    But from your message, I infer that between direct load and run of B and run of B from A, the RAM being zeroed out in the former case is the difference. If so, can you after you hit the break point at the entry point or before you branch to B from A, zero out the RAM needed by B from debugger and see if it works?

    When you run from A t o B, with debugger connected (having a break point at the branch to B from A), you see that B is starting but it doesn't hit main() of B, right? There could be only few things that are going wrong
    1.> stack for B() , make sure there is enough stack for B
    2.> A() is corrupting some data in RAM needed for B, B is assuming this RAM to be initialized certain way which might not be the case after A() is run.
    3.> B() is expecting some of the data/code in RAM, either zeroes or other constants or functions , these are available when you load B from CCS but not available when B() is started from A(). You should pay attention to any such sections (basically anything directly getting loaded to RAM in your B() liner command file).
    3.1.> Does B() call into any library that belongs to A() and is that function/data still available at the location B refers to from A, at the end of A() calling into B()?

    Would you be able to attach the map file of B() and the linker command file of B() for review, I'll see if I can point to the sections that you need to pay attention to.


    Hope this helps.

    Best Regards
    Santosh Athuru
  • Hello Santosh,

    Many thanks for your ideas !

    Let's start with the result of my tests :

    Santosh Athuru said:
    But from your message, I infer that between direct load and run of B and run of B from A, the RAM being zeroed out in the former case is the difference. If so, can you after you hit the break point at the entry point or before you branch to B from A, zero out the RAM needed by B from debugger and see if it works?

    and

    1.> stack for B() , make sure there is enough stack for B

    I tried to limit a lot the necessary stack and it seems change nothing. The assembly step by step done after the jump seems working after that. The same but with a "resume" crash leads to a "Cortex_M3_0: Can't Run Target CPU: (Error -1268 @ 0x90001) Device is locked up in Hard Fault or in NMI. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 6.0.407.3)"

    Santosh Athuru said:

    2.> A() is corrupting some data in RAM needed for B, B is assuming this RAM to be initialized certain way which might not be the case after A() is run.

    Thanks to your idea, I debug B after the jump "step by step" and it seems that RAM is properly initialized. c.f. comment after the quotes...

    Santosh Athuru said:

    3.> B() is expecting some of the data/code in RAM, either zeroes or other constants or functions , these are available when you load B from CCS but not available when B() is started from A(). You should pay attention to any such sections (basically anything directly getting loaded to RAM in your B() liner command file).

    As far as I understand my sections, I don't think having something particular in such section.

    Santosh Athuru said:

    3.1.> Does B() call into any library that belongs to A() and is that function/data still available at the location B refers to from A, at the end of A() calling into B()?

     

    I don't think having anything "crossed" symbols between A and B. You can have a look at my map file

    Let's continue with my general observation.

    I am not sure that the issue comes from the RAM loading. I am not convinced by that because I don't think debugger zeroed anything "implicitely". Moreover, doing the initialisation step by step convinced me that the RAM was initialized before being used. I was wondering if the difference was not related to some interrupts disabled by debugger, but enabled in normal condition. I tried to do a "hwi_disable" just before the jump, without success.

    Santosh Athuru said:

    Would you be able to attach the map file of B() and the linker command file of B() for review, I'll see if I can point to the sections that you need to pay attention to.

    Sure, thanks to have a look at it :

    /*
     * Copyright (c) 2013, Texas Instruments Incorporated
     * All rights reserved.
     *
     * Redistribution and use in source and binary forms, with or without
     * modification, are permitted provided that the following conditions
     * are met:
     *
     * *  Redistributions of source code must retain the above copyright
     *    notice, this list of conditions and the following disclaimer.
     *
     * *  Redistributions in binary form must reproduce the above copyright
     *    notice, this list of conditions and the following disclaimer in the
     *    documentation and/or other materials provided with the distribution.
     *
     * *  Neither the name of Texas Instruments Incorporated nor the names of
     *    its contributors may be used to endorse or promote products derived
     *    from this software without specific prior written permission.
     *
     * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
     * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
     * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
     * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
     * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
     * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
     * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
     * OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
     * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
     * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
     * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
     */
    /*
     *  ======== TMDXDOCKH52C1.cmd ========
     *  Define the memory block start/length for the F28M35H52C1 M3
     */
    
    MEMORY
    {
        BOOTROM (RX)        : origin = 0x00000000, length = 0x10000
    
        CSM_ECSL_Z1         : origin = 0x00200000, length = 0x00000024 // Reserved to avoid permanent board lock
        CSM_RSVD_Z1         : origin = 0x00200024, length = 0x0000000C // Reserved to avoid permanent board lock
        FLASH_BOOT (RWX)    : origin = 0x00200030, length = 0x00000004
        FLASH (RWX)         : origin = 0x00200034, length = 0x0001FFCC // Reserved for bootloader (part of sector N and sector M)
        RSVD_FIRMWARE (RX)  : origin = 0x00220000, length = 0x0005FF00 // Starts at sector L
        CSM_RSVD_Z2         : origin = 0x0027FF00, length = 0x000000DC // Reserved to avoid permanent board lock
        CSM_ECSL_Z2         : origin = 0x0027FFDC, length = 0x00000024 // Reserved to avoid permanent board lock
    
        C03SRAM (RWX)       : origin = 0x20000000,		length = 0x00008000
    
        /* S07SHRAM (RWX)  	: origin = 0x20008000, 	length = 0x10000	*/
    
        S05SHRAM (RWX)      : origin = 0x20008000, 		length = 0xC000
        S6SHRAM (RWX)       : origin = 0x20014000, 		length = 0x2000
        S7SHRAM (RWX)       : origin = 0x20016000, 		length = 0x2000
    
        MAC_OTP (R)         : origin = 0x680810, 	length = 0x8
    }
    
    SECTIONS
    {
        /* Allocate program areas: */
        .text       : > FLASH
        .binit      : > FLASH
        .cinit      : > FLASH
        .pinit      : > FLASH
    
        /* Initialized sections go in Flash */
        .const      : > FLASH
    
        /* Allocate uninitalized data sections: */
        .data       : > S05SHRAM
        .bss        : >> C03SRAM | S05SHRAM
        .dma        : > S05SHRAM
        .sysmem     : > C03SRAM
        .stack      : > S05SHRAM
        .cio        : > C03SRAM
        .neardata   : > C03SRAM
        .rodata     : > C03SRAM
        .args       : > C03SRAM
    
        .MtoCshared		: > S6SHRAM
        .CtoMshared		: > S7SHRAM
    
        .MACOTP : > MAC_OTP
    }
    
    __STACK_TOP = __stack + 1024;
    

    /*
     * Do not modify this file; it is automatically generated from the template
     * linkcmd.xdt in the ti.platforms.stellaris package and will be overwritten.
     */
    
    /*
     * put '"'s around paths because, without this, the linker
     * considers '-' as minus operator, not a file name character.
     */
    
    
    -l"/home/leguillou/WindowsShared/control_board_git/F28/CortexM3_bootloader/Release/configPkg/package/cfg/tcpEcho_pem3.oem3"
    -l"/opt/ti/tirtos_c2000_2_12_01_33/products/ipc_3_30_01_12/packages/ti/sdo/ipc/lib/ipc/instrumented/ipc.aem3"
    -l"/opt/ti/tirtos_c2000_2_12_01_33/packages/ti/drivers/lib/drivers_mware.aem3"
    -l"/opt/ti/tirtos_c2000_2_12_01_33/products/bios_6_41_04_54/packages/ti/sysbios/fatfs/lib/release/ti.sysbios.fatfs.aem3"
    -l"/opt/ti/tirtos_c2000_2_12_01_33/products/ipc_3_30_01_12/packages/ti/sdo/utils/lib/utils/instrumented/utils.aem3"
    -l"/home/leguillou/WindowsShared/control_board_git/F28/CortexM3_bootloader/src/sysbios/sysbios.aem3"
    -l"/opt/ti/tirtos_c2000_2_12_01_33/products/bios_6_41_04_54/packages/ti/catalog/arm/cortexm3/concertoInit/lib/Boot.aem3"
    -l"/opt/ti/tirtos_c2000_2_12_01_33/products/bios_6_41_04_54/packages/ti/targets/arm/rtsarm/lib/ti.targets.arm.rtsarm.aem3"
    -l"/opt/ti/tirtos_c2000_2_12_01_33/products/bios_6_41_04_54/packages/ti/targets/arm/rtsarm/lib/boot.aem3"
    -l"/opt/ti/tirtos_c2000_2_12_01_33/products/bios_6_41_04_54/packages/ti/targets/arm/rtsarm/lib/auto_init.aem3"
    
    --retain="*(xdc.meta)"
    
    /* C6x Elf symbols */
    --symbol_map __TI_STACK_SIZE=__STACK_SIZE
    --symbol_map __TI_STACK_BASE=__stack
    --symbol_map _stack=__stack
    
    
    --args 0x0
    -heap  0x0
    -stack 0x1000
    
    /*
     * Linker command file contributions from all loaded packages:
     */
    
    /* Content from xdc.services.global (null): */
    
    /* Content from xdc (null): */
    
    /* Content from xdc.corevers (null): */
    
    /* Content from xdc.shelf (null): */
    
    /* Content from xdc.services.spec (null): */
    
    /* Content from xdc.services.intern.xsr (null): */
    
    /* Content from xdc.services.intern.gen (null): */
    
    /* Content from xdc.services.intern.cmd (null): */
    
    /* Content from xdc.bld (null): */
    
    /* Content from ti.targets (null): */
    
    /* Content from ti.targets.arm.elf (null): */
    
    /* Content from xdc.rov (null): */
    
    /* Content from xdc.runtime (null): */
    
    /* Content from xdc.services.getset (null): */
    
    /* Content from ti.targets.arm.rtsarm (null): */
    
    /* Content from ti.sysbios.interfaces (null): */
    
    /* Content from ti.sysbios.family (null): */
    
    /* Content from ti.sysbios.family.arm (ti/sysbios/family/arm/linkcmd.xdt): */
    --retain "*(.vecs)"
    
    /* Content from xdc.runtime.knl (null): */
    
    /* Content from ti.sdo.ipc.family (null): */
    
    /* Content from ti.sdo.ipc.interfaces (null): */
    
    /* Content from ti.sysbios.rts (ti/sysbios/rts/linkcmd.xdt): */
    
    /* Content from ti.sysbios.family.arm.f28m35x (null): */
    
    /* Content from ti.catalog.arm.cortexm3 (null): */
    
    /* Content from ti.catalog.peripherals.hdvicp2 (null): */
    
    /* Content from ti.catalog (null): */
    
    /* Content from ti.catalog.arm.peripherals.timers (null): */
    
    /* Content from xdc.platform (null): */
    
    /* Content from xdc.cfg (null): */
    
    /* Content from ti.catalog.arm.cortexm3.concertoInit (ti/catalog/arm/cortexm3/concertoInit/linkcmd.xdt): */
    -u _ti_catalog_arm_cortexm3_concertoInit_Boot_entry
    SECTIONS {
        .ti_catalog_arm_cortexm3_concertoInit_flashfuncs  : LOAD = FLASH,
                                                            RUN = C03SRAM,
                                                            table(BINIT)
    }
    
    /* Content from ti.platforms.concertoM3 (null): */
    
    /* Content from ti.sysbios (null): */
    
    /* Content from ti.sysbios.hal (null): */
    
    /* Content from ti.sysbios.knl (null): */
    
    /* Content from ti.sysbios.gates (null): */
    
    /* Content from ti.sysbios.heaps (null): */
    
    /* Content from ti.sdo.utils (null): */
    
    /* Content from ti.sysbios.syncs (null): */
    
    /* Content from ti.sysbios.fatfs (null): */
    
    /* Content from ti.drivers (null): */
    
    /* Content from ti.tirtos (null): */
    
    /* Content from ti.sysbios.xdcruntime (null): */
    
    /* Content from ti.sysbios.family.arm.m3 (ti/sysbios/family/arm/m3/linkcmd.xdt): */
    -u _c_int00
    --retain "*(.resetVecs)"
    ti_sysbios_family_arm_m3_Hwi_nvic = 0xe000e000;
    
    /* Content from ti.sysbios.utils (null): */
    
    /* Content from ti.sdo.ipc (ti/sdo/ipc/linkcmd.xdt): */
    
    SECTIONS
    {
    }
    
    /* Content from ti.sdo.ipc.transports (null): */
    
    /* Content from configPkg (null): */
    
    /* Content from xdc.services.io (null): */
    
    /* Content from ti.drivers.ports (null): */
    
    
    
    /*
     * symbolic aliases for static instance objects
     */
    xdc_runtime_Startup__EXECFXN__C = 1;
    xdc_runtime_Startup__RESETFXN__C = 1;
    TSK_idle = ti_sysbios_knl_Task_Object__table__V + 0;
    
    
    SECTIONS
    {
        .bootVecs:  type = DSECT
        .vecs: load > 0x20000000
        .resetVecs: load > 0x200040
        .ti_catalog_arm_cortexm3_concertoInit_begin: load > FLASH_BOOT
    
    
    
        xdc.meta: type = COPY
    }
    
    

    A.map.txt

    /*
     * Copyright (c) 2013, Texas Instruments Incorporated
     * All rights reserved.
     *
     * Redistribution and use in source and binary forms, with or without
     * modification, are permitted provided that the following conditions
     * are met:
     *
     * *  Redistributions of source code must retain the above copyright
     *    notice, this list of conditions and the following disclaimer.
     *
     * *  Redistributions in binary form must reproduce the above copyright
     *    notice, this list of conditions and the following disclaimer in the
     *    documentation and/or other materials provided with the distribution.
     *
     * *  Neither the name of Texas Instruments Incorporated nor the names of
     *    its contributors may be used to endorse or promote products derived
     *    from this software without specific prior written permission.
     *
     * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
     * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
     * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
     * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
     * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
     * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
     * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
     * OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
     * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
     * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
     * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
     */
    /*
     *  ======== TMDXDOCKH52C1.cmd ========
     *  Define the memory block start/length for the F28M35H52C1 M3
     */
    
    MEMORY
    {
        BOOTROM (RX)         : origin = 0x00000000, length = 0x10000
    
        CSM_ECSL_Z1          : origin = 0x00200000, length = 0x00000024 // Reserved to avoid permanent board lock
        CSM_RSVD_Z1          : origin = 0x00200024, length = 0x0000000C // Reserved to avoid permanent board lock
        RSVD_BOOTLOADER (R)  : origin = 0x00200030, length = 0x0001FFD0 // Reserved for bootloader (part of sector N and sector M)
        FLASH_BOOT (RWX)     : origin = 0x00220000, length = 0x00000004
        FLASH_FIRMWARE (RWX) : origin = 0x00220004, length = 0x0005FEFC // Starts at sector xxx
        CSM_RSVD_Z2          : origin = 0x0027FF00, length = 0x000000DC // Reserved to avoid permanent board lock
        CSM_ECSL_Z2          : origin = 0x0027FFDC, length = 0x00000024 // Reserved to avoid permanent board lock
    
        C03SRAM (RWX)        : origin = 0x20000000,		length = 0x00008000
        S05SHRAM (RWX)      : origin = 0x20008000, 		length = 0xC000
        S6SHRAM (RWX)       : origin = 0x20014000, 		length = 0x2000
        S7SHRAM (RWX)       : origin = 0x20016000, 		length = 0x2000
        
        CTOMMSGRAM (R)      : origin = 0x2007F000, 	length = 0x800
        MTOCMSGRAM (RW)     : origin = 0x2007F800, 	length = 0x800
    
        MAC_OTP (R)         : origin = 0x680810, 	length = 0x8
    }
    
    SECTIONS
    {
        /* Allocate program areas: */
        .resetVecs: load > FLASH_FIRMWARE
        .text       : > FLASH_FIRMWARE
        .binit      : > FLASH_FIRMWARE
        .cinit      : > FLASH_FIRMWARE
        .pinit      : > FLASH_FIRMWARE
    
        /* Initialized sections go in Flash */
        .const      : > FLASH_FIRMWARE
    
        /* Allocate uninitalized data sections: */
        .data       : > S05SHRAM
        .bss        : >> C03SRAM | S05SHRAM
        .dma        : > S05SHRAM
        .sysmem     : > C03SRAM
        .stack      : > S05SHRAM
        .cio        : > C03SRAM
        .neardata   : > C03SRAM
        .rodata     : > C03SRAM
        .args       : > C03SRAM
        
        .MtoCshared : > S6SHRAM
        .CtoMshared : > S7SHRAM
    
        .MACOTP : > MAC_OTP
    
        //.ti_catalog_arm_cortexm3_concertoInit_begin: load > FLASH_FIRMWARE_BOOT // Not able to overwrite FLASH_BOOT...
        .ti_catalog_arm_cortexm3_concertoInit_flashfuncs  : LOAD = FLASH_FIRMWARE,
                                                            RUN = C03SRAM,
                                                            table(BINIT)
    }
    
    __STACK_TOP = __stack + 1024;
    

    /*
     * Do not modify this file; it is automatically generated from the template
     * linkcmd.xdt in the ti.platforms.stellaris package and will be overwritten.
     */
    
    /*
     * put '"'s around paths because, without this, the linker
     * considers '-' as minus operator, not a file name character.
     */
    
    
    -l"/home/leguillou/WindowsShared/control_board_git/F28/CortexM3/Release/configPkg/package/cfg/CortexM3_pem3.oem3"
    -l"/opt/ti/tirtos_c2000_2_12_01_33/products/ipc_3_30_01_12/packages/ti/sdo/ipc/lib/ipc/instrumented/ipc.aem3"
    -l"/opt/ti/tirtos_c2000_2_12_01_33/packages/ti/drivers/lib/drivers_mware.aem3"
    -l"/opt/ti/tirtos_c2000_2_12_01_33/products/bios_6_41_04_54/packages/ti/sysbios/fatfs/lib/release/ti.sysbios.fatfs.aem3"
    -l"/opt/ti/tirtos_c2000_2_12_01_33/products/ndk_2_24_02_31/packages/ti/ndk/hal/timer_bios/lib/hal_timer_bios.aem3"
    -l"/opt/ti/tirtos_c2000_2_12_01_33/products/ndk_2_24_02_31/packages/ti/ndk/os/lib/os.aem3"
    -l"/opt/ti/tirtos_c2000_2_12_01_33/products/ndk_2_24_02_31/packages/ti/ndk/hal/userled_stub/lib/hal_userled_stub.aem3"
    -l"/opt/ti/tirtos_c2000_2_12_01_33/products/ndk_2_24_02_31/packages/ti/ndk/hal/eth_stub/lib/hal_eth_stub.aem3"
    -l"/opt/ti/tirtos_c2000_2_12_01_33/products/ndk_2_24_02_31/packages/ti/ndk/tools/cgi/lib/cgi.aem3"
    -l"/opt/ti/tirtos_c2000_2_12_01_33/products/ndk_2_24_02_31/packages/ti/ndk/tools/hdlc/lib/hdlc.aem3"
    -l"/opt/ti/tirtos_c2000_2_12_01_33/products/ndk_2_24_02_31/packages/ti/ndk/tools/console/lib/console_min_ipv4.aem3"
    -l"/opt/ti/tirtos_c2000_2_12_01_33/products/ndk_2_24_02_31/packages/ti/ndk/netctrl/lib/netctrl_min_ipv4.aem3"
    -l"/opt/ti/tirtos_c2000_2_12_01_33/products/ndk_2_24_02_31/packages/ti/ndk/nettools/lib/nettool_ipv4.aem3"
    -l"/opt/ti/tirtos_c2000_2_12_01_33/products/ndk_2_24_02_31/packages/ti/ndk/hal/ser_stub/lib/hal_ser_stub.aem3"
    -l"/opt/ti/tirtos_c2000_2_12_01_33/products/ndk_2_24_02_31/packages/ti/ndk/tools/servers/lib/servers_min_ipv4.aem3"
    -l"/opt/ti/tirtos_c2000_2_12_01_33/products/ndk_2_24_02_31/packages/ti/ndk/stack/lib/stk.aem3"
    -l"/opt/ti/tirtos_c2000_2_12_01_33/products/ipc_3_30_01_12/packages/ti/sdo/utils/lib/utils/instrumented/utils.aem3"
    -l"/home/leguillou/WindowsShared/control_board_git/F28/CortexM3/src/sysbios/sysbios.aem3"
    -l"/opt/ti/tirtos_c2000_2_12_01_33/products/bios_6_41_04_54/packages/ti/catalog/arm/cortexm3/concertoInit/lib/Boot.aem3"
    -l"/opt/ti/tirtos_c2000_2_12_01_33/products/bios_6_41_04_54/packages/ti/targets/arm/rtsarm/lib/ti.targets.arm.rtsarm.aem3"
    -l"/opt/ti/tirtos_c2000_2_12_01_33/products/bios_6_41_04_54/packages/ti/targets/arm/rtsarm/lib/boot.aem3"
    -l"/opt/ti/tirtos_c2000_2_12_01_33/products/bios_6_41_04_54/packages/ti/targets/arm/rtsarm/lib/auto_init.aem3"
    
    --retain="*(xdc.meta)"
    
    /* C6x Elf symbols */
    --symbol_map __TI_STACK_SIZE=__STACK_SIZE
    --symbol_map __TI_STACK_BASE=__stack
    --symbol_map _stack=__stack
    
    
    --args 0x0
    -heap  0x0
    -stack 0x1000
    
    /*
     * Linker command file contributions from all loaded packages:
     */
    
    /* Content from xdc.services.global (null): */
    
    /* Content from xdc (null): */
    
    /* Content from xdc.corevers (null): */
    
    /* Content from xdc.shelf (null): */
    
    /* Content from xdc.services.spec (null): */
    
    /* Content from xdc.services.intern.xsr (null): */
    
    /* Content from xdc.services.intern.gen (null): */
    
    /* Content from xdc.services.intern.cmd (null): */
    
    /* Content from xdc.bld (null): */
    
    /* Content from ti.targets (null): */
    
    /* Content from ti.targets.arm.elf (null): */
    
    /* Content from xdc.rov (null): */
    
    /* Content from xdc.runtime (null): */
    
    /* Content from xdc.services.getset (null): */
    
    /* Content from ti.targets.arm.rtsarm (null): */
    
    /* Content from ti.sysbios.interfaces (null): */
    
    /* Content from ti.sysbios.family (null): */
    
    /* Content from ti.sysbios.family.arm (ti/sysbios/family/arm/linkcmd.xdt): */
    --retain "*(.vecs)"
    
    /* Content from xdc.runtime.knl (null): */
    
    /* Content from ti.sdo.ipc.family (null): */
    
    /* Content from ti.sdo.ipc.interfaces (null): */
    
    /* Content from ti.ndk.rov (null): */
    
    /* Content from ti.sysbios.rts (ti/sysbios/rts/linkcmd.xdt): */
    
    /* Content from ti.sysbios.family.arm.f28m35x (null): */
    
    /* Content from ti.ndk (null): */
    
    /* Content from ti.ndk.hal.timer_bios (null): */
    
    /* Content from ti.ndk.os (null): */
    
    /* Content from ti.ndk.hal.userled_stub (null): */
    
    /* Content from ti.ndk.hal.eth_stub (null): */
    
    /* Content from ti.ndk.tools.cgi (null): */
    
    /* Content from ti.ndk.tools.hdlc (null): */
    
    /* Content from ti.ndk.stack (null): */
    
    /* Content from ti.ndk.tools.console (null): */
    
    /* Content from ti.ndk.netctrl (null): */
    
    /* Content from ti.ndk.nettools (null): */
    
    /* Content from ti.ndk.hal.ser_stub (null): */
    
    /* Content from ti.ndk.tools.servers (null): */
    
    /* Content from ti.catalog.arm.cortexm3 (null): */
    
    /* Content from ti.catalog.peripherals.hdvicp2 (null): */
    
    /* Content from ti.catalog (null): */
    
    /* Content from ti.catalog.arm.peripherals.timers (null): */
    
    /* Content from xdc.platform (null): */
    
    /* Content from xdc.cfg (null): */
    
    /* Content from ti.catalog.arm.cortexm3.concertoInit (ti/catalog/arm/cortexm3/concertoInit/linkcmd.xdt): */
    -u _ti_catalog_arm_cortexm3_concertoInit_Boot_entry
    SECTIONS {
        .ti_catalog_arm_cortexm3_concertoInit_flashfuncs  : LOAD = FLASH,
                                                            RUN = C03SRAM,
                                                            table(BINIT)
    }
    
    /* Content from ti.platforms.concertoM3 (null): */
    
    /* Content from ti.sysbios (null): */
    
    /* Content from ti.sysbios.hal (null): */
    
    /* Content from ti.sysbios.knl (null): */
    
    /* Content from ti.sysbios.gates (null): */
    
    /* Content from ti.sysbios.heaps (null): */
    
    /* Content from ti.sdo.utils (null): */
    
    /* Content from ti.sysbios.syncs (null): */
    
    /* Content from ti.ndk.config (null): */
    
    /* Content from ti.sysbios.fatfs (null): */
    
    /* Content from ti.drivers (null): */
    
    /* Content from ti.tirtos (null): */
    
    /* Content from ti.sysbios.xdcruntime (null): */
    
    /* Content from ti.sysbios.family.arm.m3 (ti/sysbios/family/arm/m3/linkcmd.xdt): */
    -u _c_int00
    --retain "*(.resetVecs)"
    ti_sysbios_family_arm_m3_Hwi_nvic = 0xe000e000;
    
    /* Content from ti.sysbios.utils (null): */
    
    /* Content from ti.sdo.ipc (ti/sdo/ipc/linkcmd.xdt): */
    
    SECTIONS
    {
    }
    
    /* Content from ti.sdo.ipc.transports (null): */
    
    /* Content from configPkg (null): */
    
    /* Content from xdc.services.io (null): */
    
    /* Content from ti.drivers.ports (null): */
    
    
    
    /*
     * symbolic aliases for static instance objects
     */
    xdc_runtime_Startup__EXECFXN__C = 1;
    xdc_runtime_Startup__RESETFXN__C = 1;
    TSK_idle = ti_sysbios_knl_Task_Object__table__V + 76;
    
    
    SECTIONS
    {
        .bootVecs:  type = DSECT
        .vecs: load > 0x20000000
        .resetVecs: load > 0x200040
        .ti_catalog_arm_cortexm3_concertoInit_begin: load > FLASH_BOOT
    
    
    
        xdc.meta: type = COPY
    }
    
    

    B.map.txt

    To summarize my observations from today :

    The only way to have this jump working is to do the blx instruction with an "assembly step over" every other combination was failing. I am not sure to explain precisely what is the difference at the debugger level between a "resume" and an "assembly step over"...

    Thanks again,

    Best Regards,

    T.

  • Santosh,

    It seems we find a way to going forward !

    The problem is related to interrupts.

    We did not mentioned it, but we have TI/RTOS started on A side. As usual, it seems logical to mention it when you found something...

    • If we do not start the BIOS on A side, then jump, then start BIOS on B side, everything seems fine on B.
    • If we start BIOS on A side, then Hwi_disable, then Jump, then do not start the BIOS on B side, Working.
    • If we start BIOS on A side, then Hwi_disable then BIOS_exit, then jump, then start BIOS Failing (Hard fault occurs)
    • If we start BIOS on A side, then Hwi_disable, then jump, then start the bios Failing (Hard fault occurs)

    So we would prefer to have a running BIOS on both side, what are your recommendation to achieve that ? Is there a clean way to do that and "restart" the BIOS on second stage ?

    Glad to have something new after long hours of debug :)

    Best regards,

    T.

  • Santosh,

    We finally need to start BIOS on A side due to use of some drivers requiring semaphores...
    I tried to "kill" A BIOS the clean way (as recommended here), but using sys_atExit and BIOS_exit doesn't solve the issue, a HW interrupt is catched, and processor crash.

    Again, what we want to achieve is :

    A BIOS Start -> Some A code -> Jump B *-> B BIOS start -> Some B code
    (* currently this jump is failing due to use of BIOS on both side...)

    Thanks for your help,
    Best regard,

    T.

  • T,
    very interesting, I too forgot to mention interrupts before branching to B from A, I was assuming all the interrupts are masked/disabled till B re-initializes them as needed.

    I will have someone with TI RTOS experience look at this question, but looks like there is a lingering interrupt trying to fetch from what A() has initialized and before B() has a chance to re-init.

    Best Regards
    Santosh Athuru
  • Are you able to step through the BIOS_start() on the B side at all? I'm wondering if it crashes at the Hwi startup step (which is essentially a Hwi_enable()) or elsewhere?

    Thanks,
    Whitney
  • Hello Whitney,

    Yes, we are able to go inside the BIOS_start() and you are right, we are stuck in the Hwi_startup, which is only a Hwi_enable().

    Thanks for your help,

    BR,

    T.

  • Whitney,

    It crashes exactly here... on Hwi_enable().

    BR,

    T.

  • It sounds like it might be as Santosh describes--you have a lingering interrupt from the A side that's crashing the B side as soon as interrupts are re-enabled because things haven't been reinitialized properly yet.

    Can you tell which interrupt it is? In addition to calling Hwi_disable() (which disables interrupt globally) before jumping to B, you could also try disabling any specific interrupts the A side enabled (Hwi_disableInterrupt())? You may also want to consider clearing any pending interrupt flags.

    Whitney

  • We found the solution.

    Issue was coming from system tick interrupt...

    As "Hwi_disable" is poorly named, the effect is not the same as Hwi_disableInterrupt(SYSTICK)... it's not a "disable all"

    Anyway the working code is :

    #include <ti/sysbios/hal/Hwi.h>
    #include <inc/hw_ints.h>
    
    typedef void (*fptr)(void);
    const fptr Firmware_Jump_Address;
    #pragma DATA_SECTION(Firmware_Jump_Address, ".Firmware_Jump_Address") // B side set this part to _c_int00_ adress
    
    void JumpToFirmware()
    {
    	LOG_DEBUG("JumpToFirmware : jump to address 0x%08x \n", Firmware_Jump_Address);
    	// Mandatory to avoid crash bios start on next stage.
    	Hwi_disableInterrupt(FAULT_SYSTICK);
    	Firmware_Jump_Address();
    }

    Hope it can help someone one day.

    Thanks Whitney and Santosh !

    BR,

    T.