• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 701 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.

TM4C123BH6ZRB: Bootloader CCS project file from TIVA software package

yihe
Guru 67180 points
Part Number: TM4C123BH6ZRB
Other Parts Discussed in Thread: EK-TM4C123GXL,

Hello Team

I download the TIVA software package and the bootloader folder contains the source codes. but it does not includes CCS project files like other examples in the package. Where can I get it?

My purpose is to compile the bootloader and load it to the flash for a onsite update.

Regards

Yihe

  • 0
    TI__Guru 72500 points

    A CCS project for the serial bootloader can be found in the TivaWare directory:

    C:\ti\TivaWare_C_Series-2.2.0.295\examples\boards\ek-tm4c123gxl\boot_serial

    For the USB bootloader look in:

    C:\ti\TivaWare_C_Series-2.2.0.295\examples\boards\ek-tm4c123gxl\boot_usb

  • 0 in reply to Bob Crosby
    TI__Guru 67180 points

    Hello Bob

    Thank you. I was able to compile the boot_serial(with I2C update) and run it on the TM4C123BH6ZRB. I was able to communicate with the bootloader via i2C. I am using CCS9.1 and TIVA 2.2.0.295 package.

    One thing I found that when I halt the core, the code is stopped, but the codes just never stops at my breakpoints set at the same location where I halt the core from CCS

    Could you help how I can debug the boot loader with the breakpoints?

    Many Thanks

    Yihe 

  • 0 in reply to yihe
    TI__Guru 72500 points

    The issue with debugging the bootloader is that the bootloader is run from RAM, not from flash. You should not set breakpoints in the RAM locations until after the code is copied into the RAM. Unfortunately the symbols don't work until the code jumps to the RAM for execution. If the bootloader is working properly to copy the code into RAM and wait for input from the peripheral, just run the code and then halt it. You should be running from RAM in a loop checking the peripheral. If you get to this point, you can now set breakpoints and debug normally.

    If the problem is getting to that point, you will need to step the code to the point where it jumps to the RAM. I used the serial bootloader demo program. Your addresses may be different, but the method is the same. You will need to work with the disassembler window.

    Do a system reset and look at the disassembly window. The code should look something like the image below:

    My code starts at address 0x33C, which is the label ResetISR in the file bl_startup_ccs.s. At address 0x34C, there is a branch to a subroutine at address 0x300. That is the subroutine ProcessorInit(). At address 0x336 see the " orr r14, r14, 0x20000000"? That instruction changes the return address to point to the RAM. Set a breakpoint at that location, then assembly step the next two instructions. You should now be in the RAM and have normal C debug symbols.