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.

TM4C1297NCZAD: Jump from application code to flash bootloader

Part Number: TM4C1297NCZAD
Other Parts Discussed in Thread: CC3220S

HI,

What is the command use to jump from application to flash bootloader? is this the following function from boot_demo1 code?

//*****************************************************************************
//
// Passes control to the bootloader and initiates a remote software update.
//
// This function passes control to the bootloader and initiates an update of
// the main application firmware image via UART0 or USB depending
// upon the specific boot loader binary in use.
//
// \return Never returns.
//
//*****************************************************************************
void
JumpToBootLoader(void)
{
    //
    // We must make sure we turn off SysTick and its interrupt before entering 
    // the boot loader!
    //
    MAP_SysTickIntDisable(); 
    MAP_SysTickDisable(); 

    //
    // Disable all processor interrupts.  Instead of disabling them
    // one at a time, a direct write to NVIC is done to disable all
    // peripheral interrupts.
    //
    HWREG(NVIC_DIS0) = 0xffffffff;
    HWREG(NVIC_DIS1) = 0xffffffff;
    HWREG(NVIC_DIS2) = 0xffffffff;
    HWREG(NVIC_DIS3) = 0xffffffff;

    //
    // Return control to the boot loader.  This is a call to the SVC
    // handler in the boot loader.
    //
    (*((void (*)(void))(*(uint32_t *)0x2c)))(); 
}

Thanks

  • Hi Suzanne,

    Yes, for the flash bootloader that is the command you want to use. The actual jump is on line 36 but the rest is needed before making the jump so nothing can interrupt your bootloader as it works.

    Best Regards,

    Ralph Jacobi

  • HI Ralph,

    What does this line of code means? what is 0x2c? Will this jump to address 0x0 which is the start address of the flash bootloader? 

    (*((void (*)(void))(*(uint32_t *)0x2c)))();

  • Hello Suzanne,

    You can see where it goes by going to bl_startup_ccs.s in our boot_loader TivaWare folder which has the source code for the flash boot loader. It will jump to the SVCall handler which will then execute the UpdateHandler function from RAM.

    Best Regards,

    Ralph Jacobi

  • HI Ralph,

    How can i trigger updaterhandler from the flash bootloader itself? I am trying to test the update by 1st isolating the application code. Thanks

  • Hello Suzanne,

    I wouldn't see why the same jump wouldn't work in the flash bootloader if you have an area you want to modify to add in.

    You wouldn't need the TivaWare API's for that, only

        (*((void (*)(void))(*(uint32_t *)0x2c)))(); 

    Best Regards,

    Ralph Jacobi

  • HI Ralph,

    At the moment, when i run the flash bootloader, it seems to go to ProceesorInit function and loops at the copy_loop. When I pause the debugger, it seems to break at 

    while((HWREG(UARTx_BASE + UART_O_FR) & UART_FR_RXFE));
    in 

    void UARTReceive(uint8_t *pui8Data, uint32_t ui32Size)

    I am not too sure what is happening here. Can you recommend where is the best place to have the Updater called? I tried to use BL_INIT_FN_HOOK but does not seems to work. 

    #define BL_INIT_FN_HOOK         Updater

    NOTE: I am using XDS200 USB debugger.

    NOTE: I am very sure that I will be using the Updater which is via UART. so, instead of Update handler, i am directly invoking Updater. 

  • Hi Suzanne,

    Maybe I am a little unclear here but why is the boot loader being debugged? Did you change the source code for boot loader operation?

    The Flash boot loader is very thorough tested and used by 100's of customers so unless you changed it manually then you should not need to debug it at all. If you did change anything, then focus your debug on what code you added to the boot loader.

    It's not really clear to me either what is occurring because trying to debug the boot loader isn't something I am used to doing.

    Maybe taking a step back, are you trying to use a different UART port? If so which one? And did you update bl_config.h to reflect that?

    Best Regards,

    Ralph Jacobi

  • HI Ralph,

    Yes. I am using a different port and i am configuring it from bl_config.h. To give you the background, I am using CC3220S as external device to flash TIVA. On CC3220, I am using sflash source code as a base reference to execute the update. As i am trying to make it work, i am unable to get pass the 1st part which is to get ACK from TIVA flash bootloader after COMMAND_PING. That is the reason I am trying to debug from the bootloader if it was transmitted and received correctly. At the current debug setup, i am unable to even see this. I have check that the baudrate and the pins are correctly configured. I am not sure what i am doing wrongly.  

  • HI Ralph,

    I manage to find what was the issue. 

    In summary, i found out that if i jump from application, the UART line is not reconfigured in the flash bootloader. All the uart config configured by application will be retained in the flash bootloader. With this, the UART communication is working as expected. I can now proceed with the flashing. 

    BTW, from you experience, what is the maximum transfer size for UART that can be supported by the bootloader? At the moment, it is only 8bytes + command. This is taking forever. From the bl_config.h, there is a comment such as below. Is 65 the max I should set?

    //*****************************************************************************
    //
    // The number of words in the data buffer used for receiving packets.  This
    // value must be at least 3.  If using auto-baud on the UART, this must be at
    // least 20.  The maximum usable value is 65 (larger values will result in
    // unused space in the buffer).
    //
    // Depends on: None
    // Exclusive of: None
    // Requires: None
    //
    //*****************************************************************************
    #define BUFFER_SIZE             20

    If this changes, what are the corresponding parameter to change such as stack?

    Thanks

  • Hello Suzanne,

    Glad you were able to find the root cause of the issue back in the application.

    BTW, from you experience, what is the maximum transfer size for UART that can be supported by the bootloader? At the moment, it is only 8bytes + command. This is taking forever. From the bl_config.h, there is a comment such as below. Is 65 the max I should set?

    I honestly can't say I have messed with this. I don't think that it would have a discernable difference on the transfer speed because the real bottleneck is the speed of the UART interface. That is just for the data buffer and doesn't control the packet size. The data buffer would be processed easily and should not be a bottleneck. That might help more for high speed transfers over USB or Ethernet.

    If this changes, what are the corresponding parameter to change such as stack?

    I don't believe there are any given:

    // Depends on: None
    // Exclusive of: None
    // Requires: None

    Best Regards,

    Ralph Jacobi

  • HI Ralph,

    Thanks for the info. I am in a better position right now and making good progress. Thanks.