TM4C123GH6PM: Call TivaWare CAN Bootloader from Application

Hello Josua,

Are you using the ROM boot loader or a Flash boot loader?

What do you mean by "I override the bootloaders vector table (in SRAM) with the one of my application"? When does it get overwritten?

Hello Ralph,

as far as I can tell from the TivaWare Bootloader User's Guide and the Datasheet there is no ROM Bootloader for CAN (only for Serial interfaces).

Hence, I'm using the flash bootlloader.

The Bootloader starts its execution from 0x00 in flash memory, then calls the ProcessorInit() function, which copies the bootloader from flash into SRAM and continues execution from SRAM. Therefore, the bootloaders vector table now sits at the beginning of SRAM at 0x20000000. When the bootloader has successfully downloaded an application, the application's vector table is copied to this address overwriting the bootloaders vtable. At least, this is my understanding of the bootloaders operation. Please correct me if I am wrong.

Basically, this should not be a problem as a call to UpdateHander() will copy the bootloader back to SRAM restoring its vtable. However, I am clueless as to what else could cause this problem (beside the configuration that I posted).

Regards,

Josua

Hello Josua,

You're right about there not being a CAN boot loader, sorry about that, it slipped my mind that CAN was the one case where there isn't a ROM boot loader present but a Flash boot loader is!

Your understanding of how the boot loader copies Flash into SRAM and executes from there is correct.

You are using the TM4C123 and not a TM4C129 device correct? Just want to make sure because for TM4C129 I would have a very strong idea as to what is going on wrong if it were a TM4C129 device.

Since you are landing in FaultISR, I think the quickest means to get this resolved would be to get more info about what caused the FaultISR. This can be found out by following the steps in this document: www.ti.com/.../spma043

Please report back the results of what is being set that causes the FaultISR to occur and then I can help you further!

Josua Janus said:

the application's vector table is copied

This is true for TI-RTOS apps, but not in general. Are you using TI_RTOS or some other code that claims to copy the vector table to SRAM?

Regardless, this is probably not the cause of your fault because the bootloader re-copies its vector table when called. Any app modifications are overwritten.

Ralph's document will recommend you capture the PC value from the exception stack from.

Another way is to single step over your code until you hit the offending function. To do this, you need to follow this guide: https://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/t/691665

Thanks for the replies.

Yes, I am using a TM4C123 and not a TM4C129 and also, I am not using any kind of RTOS or code that is in any way complex (at least for now).

I did try to single step through the code, but I am not quite sure about the offending instruction yet.

Let me describe my approach:

First I started the bootloader in Debug mode in CCS and flashed my demo application over CAN. After a successful download, I set up a breakpoint at the SVCall instruction in the demo application.

000015d8:   202C                movs       r0, #0x2c

Then I started going through the disassembly step by step. As there were no debug symbols defined in flash, I compared the address to the address with the same offset in SRAM to find out what function is being called (e.g. 0x0000076c ->0x2000076c). 
The SVC called the UpdateHander() function, which in turn called the ProcessorInit() function of the bootloader.

0000076c:   F7FFFFC4            bl         #0x200006f8 		// UpdateHandler()
000006f8:   2000                movs       r0, #0			// ProcessorInit()

The ProcessorInit() function went through a couple of instructions and than cycled once trough the copy loop. At this point, I got a little bit suspicious. Although I do not really have a clue when it comes to assembler, I thought that the loop which copies all the code from flash to SRAM should repeat more than once.

   ;; Copy the code image from flash to SRAM.
    ;;
    movs    r0, #0x0000
    movs    r1, #0x0000
    movt    r1, #0x2000
    ldr     r2, bss_start
copy_loop:
        ldr     r3, [r0], #4
        str     r3, [r1], #4
        cmp     r1, r2
        blt     copy_loop

After that, the zero loop was called and I tried to step through it, but I could not get out of it manually in a reasonable amount of time. Also I was not really sure about what it is doing, because none of the core registers changed (except the PC of course).

    ;;
    ;; Zero fill the .bss section.
    ;;
    movs    r0, #0x0000
    ldr     r2, bss_end
zero_loop:
        str     r0, [r1], #4
        cmp     r1, r2
        blt     zero_loop

    ;;
    ;; Set the vector table pointer to the beginning of SRAM.
    ;;
    movw    r0, #(NVIC_VTABLE & 0xffff) //breakpoint here stops in loop
    movt    r0, #(NVIC_VTABLE >> 16)    //breakpoint was set at this instruction

Anyways, I tried to set a breakpoint at the first instruction after the loop, which resulted in the program still stopping in the loop. So I set the breakpoint at the second instruction after the loop, but the program never reaches this point.

When I pause the program I am in the FaulISR() of my demo application(!) and the FaultStatus register has a value of one indicating an instruction access violation. The address in the NVIC_FAULT_ADDR register is not listed in the datasheet (0xE000EDF8), but it belongs to the cortex-m4f peripherals (NVIC etc).

Next, I am going to try to inspect the exception stack as described in the guide and post the results. In the mean time, I thought that I share the insights that I made so far. Also, I would be grateful, if somebody could provide me with a little bit of clarity on the functionality of the two loops.

Best Regards,

Josua