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.

RTOS/LAUNCHXL-CC2650: Bios_Start() results in loader_exit()

Part Number: LAUNCHXL-CC2650
Other Parts Discussed in Thread: SYSBIOS, TM4C1294NCPDT,

Tool/software: TI-RTOS

Hi,

I've tried to step into Bios_Start() to see what might be going on, but it immediately jumps to loader_exit().  I'm not sure how to proceed debugging this problem.  Since this is a fresh version of Project Zero it certainly should be working correctly.  

Can't say I'm terribly surprised by this, I've come across many TI demos that do not work out of the box (in fact it's more likely they don't work from experience.)

Any routes of investigation I should take?  Thanks!

  • Hi David,

    Please make sure you are using the debug version of the SysBios library so that the BIOS_Start() code is not optimized (optimized code does not work well with stepping at the source level). To use the debug library, you need to change this line in your project's .cfg file:

    BIOS.libType = BIOS.LibType_Custom;

    to

    BIOS.libType = BIOS.LibType_Debug;

    Rebuild the program, and try to step into BIOS_Start() again.

    Best regards,
    Vincent
  • I switched the commented lines in app_ble_uartlog.cfg which now reads:
    //BIOS.libType = BIOS.LibType_Custom;
    BIOS.libType = BIOS.LibType_Debug;

    There is no change in the behavior. I cannot step into Bios_start(). I was unable to locate any other .cfg files.
  • Which version of CCS and CC26XX SDK (or TI-RTOS) are you using? Have you tried using the Disassembly View (Window->Show View->Disassembly) to set a breakpoint on the symbol name 'BIOS_start' and see if the breakpoint is hit when you run? Normally I'd expect the source file containing BIOS_start to just open up in CCS when the assembly breakpoint is hit.
  • CCS: 6.2.0.00050

    SDK: ble_sdk_2_02_01_18

    RTOS:  tirtos_cc13xx_cc26xx_2_20_01_08

    Edit: Compiler versions 5.2.6 and 5.2.9 have both been used in addition to the default 15.12.4.LTS.  There are slight variations in the disassembly (expected) but all result in the same loader_exit() loop.

    In viewing the disassembly I do see some odd behavior.  It seems to load the PC into itself, which (I believe) might cause an infinite loop that might cause a hardware exception of some kind.  It seems to crash on the line:

    153         ProjectZero_createTask();
    0000a574:   F7FFFD3A            bl         #0x9fec
    156         BIOS_start();
    0000a578:   F000F804            bl         #0xa584
    160         return 0;
    0000a57c:   2000                movs       r0, #0
    0000a57e:   BD08                pop        {r3, pc}
              $C$CON548:
    0000a580:   F0B80001           .word       0x0001f0b8
              $Tramp$TT$L$PI$$ti_sysbios_BIOS_start__E():
    0000a584:   F8DFF000            ldr.w      pc, [pc, #0] // *crash here* this is a problem line I believe, and if I put a breakpoint on the next line I end up in loader_exit()
    0000a588:   C055                stm        r0!, {r0, r2, r4, r6}
    0000a58a:   1001                asrs       r1, r0, #0x20

    My two thoughts are that the PC shouldn't be loaded into itself (ever) and that this would likely cause an infinite loop on itself (thereby causing an exception).

    Edit 2:  If I step over the line I labelled as the offending line it will go to loader_exit().  If I step into it it will continue execution for a significant number of lines before entering loader_exit().

  • Hi David,

    When I try importing and building the ProjectZeroApp example, I see that the example is built with whole program optimization turned on. You would need to turn this off if you wish to properly step thru code.

    That said, I am unsuccessful in running the example as well. I will get someone to move this thread to the device forum where someone more knowledgeable about this example can help.

    Best regards,
    Vincent
  • David,

    Per Vincent's comment, I went ahead and moved this thread over to the BLE forum in hopes that your question can get an answer there.
  • I have run into this same (or similar) issue myself working with RTOS example problems for TIVA TM4C1294NCPDT in the past few weeks.  For me I found that my target "platform" under general project parameters wasn't correct.  Once I fixed this issue, my program worked as expected.  Let me know if this helps.

    Ryan

  • I like the suggestion, but I'm still getting the same end result.  The build profile was set to release already so I tried debug and it took longer to build but there was ultimately no difference in the end result.

    I tried explicitly setting a linker file, but doing so seems to cause compiler issues.  It redefines a few things and conflicts with FLASH memory configurations.

    <Linking>
    "c:/ti/simplelink/ble_sdk_2_02_01_18/src/common/cc26xx/ccs/cc26xx_app.cmd", line 98: error #10263: FLASH memory range has already been specified
    "c:/ti/simplelink/ble_sdk_2_02_01_18/src/common/cc26xx/ccs/cc26xx_app.cmd", line 98: error #10264: FLASH memory range overlaps existing memory range FLASH
    "c:/ti/simplelink/ble_sdk_2_02_01_18/src/common/cc26xx/ccs/cc26xx_app.cmd", line 104: error #10264: FLASH_LAST_PAGE memory range overlaps existing memory range FLASH
    "c:/ti/simplelink/ble_sdk_2_02_01_18/src/common/cc26xx/ccs/cc26xx_app.cmd", line 109: error #10263: SRAM memory range has already been specified
    "c:/ti/simplelink/ble_sdk_2_02_01_18/src/common/cc26xx/ccs/cc26xx_app.cmd", line 109: error #10264: SRAM memory range overlaps existing memory range SRAM
    "c:/ti/simplelink/ble_sdk_2_02_01_18/src/common/cc26xx/ccs/cc26xx_app.cmd", line 146: warning #10190-D: absolute symbol "__STACK_TOP" being redefined
    "c:/ti/simplelink/ble_sdk_2_02_01_18/src/common/cc26xx/ccs/cc26xx_app.cmd", line 146: warning #10190-D: absolute symbol "__STACK_TOP" being redefined
    "c:/ti/simplelink/ble_sdk_2_02_01_18/src/common/cc26xx/ccs/cc26xx_app.cmd", line 146: warning #10190-D: absolute symbol "__STACK_TOP" being redefined
    error #10010: errors encountered during linking; "project_zero_app_cc2650launchxl.out" not built
    gmake: *** [project_zero_app_cc2650launchxl.out] Error 1

    CC2650F128 is the board setting.  I'll look into whether there is one specifically for the launchxl-cc2650.