CCS Debugging with usb boot loader + SafeRTOS + LM3S9B96

jayteemo

Our device uses the modified boot_usb project as a USB boot loader. The application code runs SafeRTOS.

When the boot loader and application code are flashed onto the device it runs/operates properly.

However, when attempting to debug (CCS 4.2.3.00004) the application code, the SafeRTOS function xTaskStartScheduler() returns an error code -27 (errERROR_IN_VECTOR_TABLE). I assume this has something to do with the fact that the boot loader lives in the usual vector space?

I'm able to debug properly by changing the linker to set the APP_BASE at 0x0000 (normally APP_BASE is 0x1800). I've created a separate build configuration exclusively for debug, with the modified linker. It would be nice to be able to debug using the same configuration.

Is there a better way to do this?

over 14 years ago

0 Bobby Bradford over 14 years ago

TI__Genius 10040 points

What have you set the Vector Table Base value in the xPORT_INIT_PARAMETERS table to? This is used in the call to vTaskInitializeScheduler.

In the debugger, can you set a breakpoint in the code just before the call to vTaskInitializeScheduler to see what the content of that table is? Then at the call to xTaskStartScheduler ... to see if the table has somehow been changed?

My guess at this time is that the value of NVIC_VTABLE is incorrect when you startup your application in the debugger, since the USB boot loader will normally set this up prior to starting you main application. This may not be occurring in the debug session.

--Bobby

0 jayteemo over 14 years ago in reply to Bobby Bradford

Intellectual 490 points

The vector table base is set in the application code as follows:

g_sSafeRTOSPortInit.pulVectorTableBase = (unsigned portLONG *)HWREG(NVIC_VTABLE);

When debugging with the boot loader loaded and APP_BASE correctly set at 0x1800 in the linker, the value of g_sSafeRTOSPortInit.pulVectorTableBase is 0x0000, and not 0x1800 as it should be.

I assume that, when debugging the application code, the boot loader is not executed and the code jumps directly to the application's main()?
So as you stated, the vector setup performed by the boot loader (in bl_startup_css.s), is skipped when debugging.

0 Bobby Bradford over 14 years ago in reply to jayteemo

TI__Genius 10040 points

Some debuggers will set a breakpoint at "main" and simply run from a hardware reset, which would run the boot loader code. Others will extract the entry point (reset vector) from the application and fix up the processor registers to start directly from there, bypassing the boot loader. I am guessing (though I have not confirmed this) that CCS behaves this way.

I will copy/move this thread over to the CCS forum. They should be able to provide you with additional answers on this startup sequence of the debugger.

--Bobby

0 Ryan Lush67904 over 13 years ago in reply to Bobby Bradford

Expert 1140 points

I am having a similar problem compiling the safertos_demo with Code Composer Studio. Initially I couldn't even get the project to compile but then I copied lm3s9b96.map cmd file from C:\Program Files (x86)\Texas Instruments\ccsv4\arm\include over to the top of the safertos_demo project and renamed it to safertos_demo_ccs.,map and the project compiled. I'm missing some linker settings but I don't know which ones and I don't know how to change them. This is the cmd file.

--retain=g_pfnVectors

MEMORY
{
    FLASH (RX) : origin = 0x00000000, length = 0x00040000
    SRAM (RWX) : origin = 0x20000000, length = 0x00018000
}

SECTIONS
{
    .intvecs:   > 0x00000000
    .text   :   > FLASH
    .const :   > FLASH
    .cinit :   > FLASH
    .pinit :   > FLASH

    .vtable :   > 0x20000000
    .data   :   > SRAM
    .bss    :   > SRAM
    .sysmem :   > SRAM
    .stack :   > SRAM
}

__STACK_TOP = __stack + 256;

I know I am supposed to reserve the first 524 bytes or so for the safeRTOS kernel but I am not sure how to do that.

Help?

0 Ryan Lush67904 over 13 years ago in reply to Ryan Lush67904

Expert 1140 points

I changed

SRAM (RWX) : origin = 0x20000000, length = 0x00018000

to be

SRAM (RWX) : origin = 0x20000210, length = 0x00018000

and everything appears to work now. Everything this is always so much simpler than what I initially make it out to be. Will I really need to pull the default lm3s9b96.cmd file from the Texas Instruments directory into my project directory and rename it? Why are there linker scripts for every other compiler but not CCS?

Code Composer Studio™︎

Code Composer Studio forum

CCS Debugging with usb boot loader + SafeRTOS + LM3S9B96