• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 374 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TM4C1294NCPDT: TivaWare Boot Loader - multiple interfaces in Flash bootloader

Benjamin Sprague
Prodigy 210 points
Part Number: TM4C1294NCPDT

I need to use the TivaWare boot loader to support firmware updates over both Ethernet and UART. I have done this using the ROM boot loader. Now I am trying to move to the Flash boot loader in order to utilize the CRC functionality and I have successfully implemented the boot_emac_flash example. I would now like to incorporate the UART interface into this boot loader but the enables in bl_config.h seem to be mutually exclusive.

Is there an easy way to combine these interfaces into a single boot loader (similar functionality to ROM boot loader) or do I need to create separate images for each?

  • 0
    TI__Guru*** 134805 points

    Hello Benjamin,

    Given how our ROM boot loader works, it should be possible to do that. You'd need to setup the bl_config file for both interfaces.

    The flash boot loader is based heavily off the ROM one, so I presume it already includes the ability to cycle through multiple interfaces if available. I would say start with that, and let us know if you are seeing only one interface working which would then indicate there is something else that needs to be addressed. 

    I expect this will be quite simple though, and definitely should not need two images.

  • 0 in reply to Ralph Jacobi
    Prodigy 210 points

    Ralph,

    Thanks, this is what I would expect as well and I will attempt to test it, but the bl_config explicitly describes them as being mutually exclusive. Example of Ethernet enable below:

    //*****************************************************************************
//
// Selects Ethernet update via the BOOTP/TFTP protocol.
//
// Depends on: None
// Exclusive of: CAN_ENABLE_UPDATE, I2C_ENABLE_UPDATE, SSI_ENABLE_UPDATE,
//               UART_ENABLE_UPDATE, USB_ENABLE_UPDATE
// Requires: CRYSTAL_FREQ
//
//*****************************************************************************
#define ENET_ENABLE_UPDATE

  • 0 in reply to Benjamin Sprague
    TI__Guru*** 134805 points

    Hi Benjamin,

    I took a look through the source code we provide in TivaWare and it seems the flash Ethernet boot loader is handled differently from what I expected, I need to look into this further to see what can be done but it may be trickier than I anticipated.

    By the way, do you need to use flash boot loader for both Ethernet and UART? Just want to assess if it's possible for you to maybe trigger a flash boot loader for one interface and a ROM boot loader for another. That could be another means to handle this.

  • 0 in reply to Ralph Jacobi
    Prodigy 210 points

    Ralph,

    Thanks for the update. I look forward to hearing more.

    Since we would like CRC capability, I think we'd prefer to use flash for both, but I'll give this some thought.

    Ben

  • 0 in reply to Benjamin Sprague
    TI__Guru*** 134805 points

    Hi Benjamin,

    Alright did some more digging on this topic.

    The bootloader will branch in the following manner:

        ;;
    ;; Branch to the update handler.
    ;;
.if $$defined(ENET_ENABLE_UPDATE)
    .ref    UpdateBOOTP
    b       UpdateBOOTP   
 .elseif $$defined(CAN_ENABLE_UPDATE)
    .ref    UpdaterCAN
    b       UpdaterCAN
.elseif $$defined(USB_ENABLE_UPDATE)
    .ref    UpdaterUSB
    b       UpdaterUSB
.else
    .ref    Updater  ;; for UART
    b       Updater  
 .endif
    .endasmfunc

    So based on this, you wouldn't be able to enable both of them without adjusting the boot loader.

    What you would basically need to do is find a way to cycle between the two so both interfaces are being checked, and then whichever gets communicated with first is used for the boot loader operation.

    The ROM boot loader does this with an NMI ISR from what I am seeing.