• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 53 subscribers
  • Views 2733 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/TM4C123GH6PGE: How to debug "bootloader" in CCS ?

Ian Chiu
Prodigy 70 points
Part Number: TM4C123GH6PGE


Tool/software: Code Composer Studio

Hi,

I'm trying to debug bootloader in CCS. But I can't find the way to do it.

I'm using TM4C123GH6PGE (aka. dk-tm4c123g) and the program is "boot_serial".

I pressed the button "Debug boot_serial" in CCS and try to press F5/F6 on my keyboard (Assembly Step Into/ Assembly Step Over).

But I got the error message: 

CORTEX_M4_0: AutoRun: Target not run as the symbol "main" is not defined
CORTEX_M4_0: Error: Debug Port error occurred.

and I still can't run into Updater() in bl_main.c.

How could I run the "boot_serial" and set the break point on it to know how it works?

Is any configuration should I set in properties?

Best Regards,

Ian

  • 0
    Guru 92251 points

    Ian Chiu said:
    But I got the error message: 

    CORTEX_M4_0: AutoRun: Target not run as the symbol "main" is not defined
    CORTEX_M4_0: Error: Debug Port error occurred.

    The default CCS Auto Run and Launch Options will cause CCS to run to main when starting a debug session. The bootloader doesn't have a main function which causes the "AutoRun: Target not run as the symbol "main" is not defined" error.

    Try either:

    a) Setting the "Run to symbol" in the Auto Run and Launch Options to ConfigureDevice. When starting a debug session the debugger should halt when the ConfigureDevice C function is reached.

    b) Unticking "On a program load or reset" in the Auto Run and Launch Options. When starting a debug session the debugger will halt at the reset vector, and you can step through the assembler start-up code.

  • 0 in reply to Chester Gillon
    Prodigy 70 points

    Chester Gillon said:

    Ian Chiu
    But I got the error message: 

    CORTEX_M4_0: AutoRun: Target not run as the symbol "main" is not defined
    CORTEX_M4_0: Error: Debug Port error occurred.

    The default CCS Auto Run and Launch Options will cause CCS to run to main when starting a debug session. The bootloader doesn't have a main function which causes the "AutoRun: Target not run as the symbol "main" is not defined" error.

    Try either:

    a) Setting the "Run to symbol" in the Auto Run and Launch Options to ConfigureDevice. When starting a debug session the debugger should halt when the ConfigureDevice C function is reached.

    b) Unticking "On a program load or reset" in the Auto Run and Launch Options. When starting a debug session the debugger will halt at the reset vector, and you can step through the assembler start-up code.

    Hi Chester,

    Thank you very much!

    I have tried both:

    a) Setting  the "Run to symbol" to "ConfigureDevice" and starting a debug session. But it still can't halt when the ConfigureDevice C function is reached.

    When the program starts, I even can't press F5 or suspend.

    b) Unticking "On a program load or reset" and starting a debug session. But it looks like nothing changed. Program starts at line 652 _c_int00.

    I keep press F5 and program go to "0000040c: E7FEE7FE   udf  #0xee7e" 

    Is anything wrong when I do the setting?

    Best Regards,

    Ian

  • 0 in reply to Ian Chiu
    Guru 92251 points

    Ian Chiu said:
    I keep press F5 and program go to "0000040c: E7FEE7FE   udf  #0xee7e"

    Looking at the contents of TivaWare_C_Series-2.1.3.156\boot_loader\bl_startup_ccs.s the assembler function ProcessorInit is used to copy the code from flash to SRAM and then jumps to the code in SRAM.

    The disassembly screenshot shows the program counter in SRAM at address 0x20000416 but the code doesn't look valid. Has the ProcessorInit assembly function copied the code from flash to SRAM?

    Or if you refresh the disassembly view when _c_int00() is reached do the displayed instructions change?

    [I think the CCS disassembly view may cache some old data any may get confused after code is copied to SRAM by the running program] 

  • 0 in reply to Chester Gillon
    Prodigy 70 points

    Chester Gillon said:

    Ian Chiu
    I keep press F5 and program go to "0000040c: E7FEE7FE   udf  #0xee7e"

    Looking at the contents of TivaWare_C_Series-2.1.3.156\boot_loader\bl_startup_ccs.s the assembler function ProcessorInit is used to copy the code from flash to SRAM and then jumps to the code in SRAM.

    The disassembly screenshot shows the program counter in SRAM at address 0x20000416 but the code doesn't look valid. Has the ProcessorInit assembly function copied the code from flash to SRAM?

    Or if you refresh the disassembly view when _c_int00() is reached do the displayed instructions change?

    [I think the CCS disassembly view may cache some old data any may get confused after code is copied to SRAM by the running program] 

    Hi Chester,

    Thank you very much!

    Q: Has the ProcessorInit assembly function copied the code from flash to SRAM?

    A: I'm not sure if it copied from flash to SRAM correct. However, if I let program "free run" and it work fine every time. (not in debug session)

     Q: if you refresh the disassembly view when _c_int00() is reached do the displayed instructions change?

    A: I tried. But it didn't change anything.

    But I got a good news!

    After I changed STACK_SIZE in bl_config.h form 48 to 1024.

    Everything I want to add in boot loader works perfect!!  :)

    But I still want to know how to debug bootloader :(

    Best Regards,

    Ian