• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 32 subscribers
  • Views 754 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CCS/TM4C123BH6ZRB: CCS Cannot debug main application with Custom UART Bootloader at 0x0..

Newman
Expert 6005 points
Part Number: TM4C123BH6ZRB


Tool/software: Code Composer Studio

Hi Team CCS,

Customer reports..

"This issue applies to the Bootloader program for the TM4C123.. discovered that we cannot debug the application software with the Bootloader at 0x0 and the application software bumped up to 0xc00. Oddly though, the application software runs out of Flash without the debugger.

The application software crashes on the debugger when main() enables interrupts. Although it’s tough to tell where the code might go after enabling interrupts, the Program Counter after I halt the debugger is at 0x02FC. The Call Stack Window says [__iar_systems$$module + 0x2fb]. This address is consistent with the Program Counter. Any jump to the Vector Table should be at address 0xc00 or above. Since this error referenced an IAR symbol which I could not find information on, we checked w/ IAR.

 IAR said they have seen this problem before and suggested that CPU manufacturer-supplied startup code often resets VTABLE back to 0x0, overwriting the change made in the IAR linker file. But, cannot see where TI-supplied code is doing this. IAR offered a partial solution by setting the VTABLE back to 0xc00 first-thing inside main(). We used the TI-supplied CPU_RegisterWrite() function to set VTABLE back to 0c00. I’m not sure this is the best solution. We’re thinking we need to change the TI-supplied startup code so that VTABLE is not changed back to 0x0.  

 The IAR proposed solution seems a little less than optimal.

 Have you seen this issue before?

 Do we already have a workaround for this?

 Is the source available for the startup function? If so, where?"

 Thanks, Merril

  • 0
    TI__Guru 72500 points
    I do not use IAR. The source for the startup code supplied by TI can be found in:
    C:\ti\TivaWare_C_Series-2.1.4.178\examples\project\startup_ewarm.c

    If the application code is working correctly from power-on reset without the IAR debugger connected, I don't see how the startup code is at fault. Does the IAR tool support doing a system reset (like Code Composer Studio)? The issue may be that some of the initialization done in the bootloader is necessary before running your application. The bootloader may be responsible for changing the location of the vector table.
  • 0 in reply to Bob Crosby
    Intellectual 270 points
    Your suggestion above led me to debug the bootloader, starting at ProcessorInit. But the bootloader is not debugging out of the box. I get "Warning: __vector_table symbol not found. e_entry value 0x200002b4 does not match reset vector value: 0x000002b4. Initial SSP_main value: 0x200005f4 uncertain." And when the debugger is configured to "Run to ProcessorInit" in Flash, it does not stop there. It winds up at 0x200002b4 in RAM.

    Anyway, I don't see where the bootloader code is "changing" the VTABLE register. In fact, it seems neither the bootloader or my application are setting the VTABLE register to 0xc00. It's always 0x0 until I write it in main() of my application per IAR's suggestion. BTW, the bootloader is TI's: TivaWare_C_Series-2.1.4.178/examples/boards/dk-tm4c123g/boot_serial.
  • 0 in reply to David Brooks74
    TI__Guru 72500 points
    Does the define for "VTABLE_START_ADDRESS" in "bl_config.h" of the boot_serial project also point to address 0xC00?
  • 0 in reply to David Brooks74
    TI__Guru 72500 points

    I see where the boot loader should be changing the vector table starting address. It is in bl_startup_ewarm.S starting on line 537 317. Not sure why it is not happening yet. I am still looking.

  • 0 in reply to Bob Crosby
    Intellectual 270 points

    I'm my case, APP_START_ADDRESS and VTABLE_START_ADDRESS are both 0xc00. And it looks like this is where the vector table is copied from Flash to RAM, but I don't see any initialization of the VTABLE register. So, its just left at 0x0, but it would seem the bootloader should do this prior to calling the application.

  • 0 in reply to David Brooks74
    TI__Guru 72500 points
    Using Code Composer Studio and boot_serial, I see the NVIC_VTABLE being initialized by the boot loader before transferring to the application code. I cannot see why with IAR it would not be the same. Could it be that when you are trying to debug the application code the IAR debugger is starting from the application entry point instead of executing from a system reset? In that case, the boot loader would not run and the NVIC_VTABLE register would not be initialized. That would also explain why it works without the debugger.