• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 1573 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.

TMS570LS0432: Custom Bootloader to Application Firmware

Gustavo Del Valle
Prodigy 90 points
Part Number: TMS570LS0432


Hello,

I am having trouble getting the application firmware running at all after having jumped from the bootloader. I have read a few threads but have not been able to resolve my issue. I am hoping you can help me get this sorted out. 

The bootloader is mapped to 0x00000000 and application firmware is mapped to 0x00040000.

Currently, my application firmware does not move the Fapi to RAM and .intvecs for the application are placed at 0x00040000 and application firmware at 0x00040020. The application is called from the bootloader at 0x00040000 and running the debugger, it ends at prefetchEntry of the bootloader (0x0000001C).

1. Both the bootloader and the application firmware make use of the Fapi. Should both pieces of code move the Fapi to RAM?

2. Can both pieces of code share the same .intvecs? Or should the application have .intvecs of its own placed ahead of the application (ie .intvecs should be at 0x00040000 and application should move to 0x00040020?) If the application is to have its own .intvecs mapped, is there anything I need to do before jumping to the application?

Thanks in advance!

  • 0
    TI__Guru 59540 points

    Hello Gustavo,

    The jump to Ox40000 is quite far to jump. Have you tried a smaller branch to see if this helps? I think the examples provided in our boot loader app notes and sample code uses 0x20000. Even 0x20000 is rather large for this device. You should align the jump to a sector boundary for convenience of FAPI operations. The first 12 sectors are 8k sectors allowing the jump address to be any of the 0x2000 addresses between 0x2000 to 0x16000. When performing the jump, please make sure you maintain the operational mode, i.e. ARM or Thumb modes. The hercules device usually default to ARM mode on reset so this shouldn't be a concern. 

    Gustavo Del Valle said:
    2. Can both pieces of code share the same .intvecs? Or should the application have .intvecs of its own placed ahead of the application (ie .intvecs should be at 0x00040000 and application should move to 0x00040020?) If the application is to have its own .intvecs mapped, is there anything I need to do before jumping to the application?

    The interrupt vector table has to be located at 0x0000000. The boot loader user guides (except the SPI UG below) outlines how to address use of interrupts with your boot loader.

    Here are some links to 3 different boot loader implementations for the LS0432:

    SPI Bootloader for Hercules TMS570LS04X MCU

    UART Bootloader for Hercules TMS570LS04X MCU

    CAN Bus Bootloader for TMS570LS04X MCU

    Gustavo Del Valle said:
    1. Both the bootloader and the application firmware make use of the Fapi. Should both pieces of code move the Fapi to RAM?

    Yes, both could share the same instantiation of the FAPI but given you may want to periodically update the FAPI on the device and you may want to use the latest and greatest for programming, you may choose to implement a bit differently.

    First, you may want to make the boot loader FAPI independent such that the FAPI is loaded to RAM over the serial protocol of choice. i.e., you connect, download the FAPI to RAM and jump to it for write/erase operations and flow control of data coming in. This way the boot loader is a simple command interface with no FAPI and data management code needed. The gain is efficiency in the size of your boot loader, security in case someone learns to break into your boot loader, and the ability to update the program load/erase object code independently of the device.

    The alternative choice would be have the FAPI in flash. Sharing between the application and the boot loader is really dependent on your system requirements. Having an interdependence between the boot loader and the application on common code could be a safety concern or further complicate programming. i.e., if the FAPI is part of the boot code, you would have to access the boot section for application run time making MPU settings difficult to isolate the application from the boot loader. If the FAPI is stored in the application area, again, this is an issue for isolation of the two operations from a safety point of view.

  • 0 in reply to Chuck Davenport
    Prodigy 90 points
    Hi Chuck,

    Thank you for the response. That's what was happening - the firmware would call the bootloader API functions and that's where the problem was.

    I was able to get the firmware running properly with the bootloader by making separate sections in flash for the FAPI library and the interface code to the API. The interface code in the bootloader and the firmware are the same size. Now, depending on which code is running, its interface code would be loaded to the designated RAM section allocated by the liker file.

    I do have another question, however. I am using the following lines in the post-build section to create a .bin file:

    "${CCS_INSTALL_ROOT}/utils/tiobj2bin/tiobj2bin.bat" "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.bin" "${CG_TOOL_ROOT}/bin/armofd.exe" "${CG_TOOL_ROOT}/bin/armhex.exe" "${CCS_INSTALL_ROOT}/utils/tiobj2bin/mkhex4bin.exe"

    This turns the .out into a .bin, however, is it possible to determine a specific section of the flash to convert to .bin from the .out file? If that is not the case, how would I go about doing that? Currently, I am saving the flash from the micro with the specific memory range where the firmware is located into a .bin file. This takes quite a bit of time, it would be very useful if I can do this from within CCS.

    Thank you,

    Gustavo Del Valle
  • 0 in reply to Gustavo Del Valle
    TI__Guru 59540 points

    Hello Gustavo,

    This is a relatively easy fix. Simply modify the Flash memory definitions for the start of Flash in the Linker Command file. See the snippet below from the CAN Bootloader application note (section 10)  I linked to earlier in this thread.

  • 0 in reply to Chuck Davenport
    Prodigy 90 points
    Hi Chuck,

    Thanks for all your support. Everything is working as expected now.

    Thanks,

    Gustavo Del Valle