Custom Bootloader Design: Works Fine except getting UART_ISR Call

We are working on a custom bootloader for a product. The bootloader was done by generating a standalone project in PE (exported to Keil) with limited peripherals such as I2C and UART. We then created the main application project in PE as well (also exported to Keil). Both projects have flash Read/Write Components added in PE as well. Both run perfect, when loaded independently in Keil, using the default Flash Start addresses.

Now we took the bootloader project to read a specific place in flash to determine to whether to implement a DFU or to jump to the default application default application. We then design a function to make the jump using _asm{}, We then placed the application where the jump position is, and the application does get executed if we choose not to do a DFU. The bootloader jumps to the application correctly if we choose to not implement a DFU. However after the application starts, we enter pe_low_level_init() and after this is executed, we are constantly getting hit my UART_ISR() even though there is no UART traffic. If we disable all of the INTs, it goes away, but our application will not work as we use INTs all over the place.

The PE projects for both the bootload and the application are almost identical except additional, non-PE generated code (application code), so the interrupt vectors and such should be the same, but it seems we're getting UART_ISR firiing for no reason.

Here are some more details:

- Same exact INTs are in Bootloader and Application: UART, I2C, BitIOs, etc: The bootloader project is actually a copy of the application project that is mildly stripped down.

- Do INTs need to be deinitialized before the jump is made? It seems when we make the jump, the new PE_low_level_init() function, something is not being reinitialized correctly.

**Device: KL15 in 35WLCSP, 128K Flash, 16KB RAM, on custom HW circuit, which has been verified and used with various PE projects...all other projects do not have issues, so this is a pure SW/Bootloader issue

You should disable interrupts before jumping to application. Then usually in the application startup code all pending interrupts should be cleared, to ensure that no interrupts remain from the bootloader and have a "fresh" start.

Also, I guess you have 2 separate vector tables (bootloader and application). Make sure the application's startup code updates VTOR register to point to the application's vector table.

Finally, it would be rare, but the interrupt actually firing might not be the UART interrupt. Confirm the vector number by looking at the register ICSR when debugging, the bit field [8-0] will tell you the active interrupt vector, then you can check the number in the Reference Manual (Interrupt Channel Assignments).

We figured it out, and actually what we did was just de-initialize all of the drivers before we jumped, since they are all reinitialized after the jump when we enter main code application "pe_low_level_init"

What was odd is that it was only coming from UART INT....and we checked and double checked the vector tables to make sure they were aligned, and they were.

Part of de-initializing the driver means disabling the module interrupts (TX and RX), so yes I think that is a valid solution.

I don't know for sure but the interrupt might be caused by the TDRE flag. If the flag was set and TDRE interrupts enabled prior to the jump, then the UART interrupt would trigger as soon as the UART vector was enabled from the NVIC module, which happens during PE_low_level_init().