TM4C1297NCZAD: Jump from application code to flash bootloader

Suzanne Lim

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

over 4 years ago

0 Ralph Jacobi over 4 years ago

TI__Guru*** 135355 points

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

0 Suzanne Lim over 4 years ago in reply to Ralph Jacobi

Prodigy 220 points

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)))();

0 Ralph Jacobi over 4 years ago in reply to Suzanne Lim

TI__Guru*** 135355 points

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

0 Suzanne Lim over 4 years ago in reply to Ralph Jacobi

Prodigy 220 points

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

0 Ralph Jacobi over 4 years ago in reply to Suzanne Lim

TI__Guru*** 135355 points

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

0 Suzanne Lim over 4 years ago in reply to Ralph Jacobi

Prodigy 220 points

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));

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.

0 Ralph Jacobi over 4 years ago in reply to Suzanne Lim

TI__Guru*** 135355 points

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

0 Suzanne Lim over 4 years ago in reply to Ralph Jacobi

Prodigy 220 points

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.

0 Suzanne Lim over 4 years ago in reply to Suzanne Lim

Prodigy 220 points

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

+1 Ralph Jacobi over 4 years ago in reply to Suzanne Lim

TI__Guru*** 135355 points

Hello Suzanne,

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

Suzanne Lim said:
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.

Suzanne Lim said:
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

0 Suzanne Lim over 4 years ago in reply to Ralph Jacobi

Prodigy 220 points

HI Ralph,

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

Arm-based microcontrollers

Arm-based microcontrollers forum

TM4C1297NCZAD: Jump from application code to flash bootloader