I have developed an application based on FreeRTOS, as a standalone application (no bootloader) it works fine, however when I use bootloader with it, it goes into the general exception handler. Bootloader jumps to the application normally however as soon as the application starts it hits the general exception. I am using PIC32MZ2064DAB169 microcontroller.
To troubleshoot this problem I created a bare minimum FreeRTOS application and a bare minimum bootloader. The application just toggles the led in a task and bootloader just jumps on to the start address of application but to my surprise the application hits the general exception also. One note that I would like to add is the general exception hits when a button is pressed, button is attached to external hardware interrupt of microcontroller.
I have confirmed the linker scripts of both bootloader and application are fine in terms of mapping the interrupt vector table. I have checked the memory map file as well and it perfectly reflects what is coded in linker script.
I am trying to resolve this problem for a week now, I have no clue what the issue is, guidance is appreciated.
Can you try writing a bare metal application and see if you are able to jump to the application from boot-loader and run it correctly?
Looks like the interrupts are not working correctly.
See if this application note is of any help - https://ww1.microchip.com/downloads/en/Appnotes/01388B.pdf
Thanks for your response @aggarg
Yes bare-metal application works fine with bootloader.
I have gone through this document earlier, I don’t any thing in my code that violates their guidelines and bare metal application is running fine as well, I am wondering what could be the issue, I have checked online if there is a solution, but unfortunately there is nothing online that can come useful in this problem…
One issue I have seen with some bootloaders is they enter the application in not the same state as it would be entered if it was a “non-boot loader” application. Perhaps interrupts start enabled or something else not in reset state, that causes the application to crash if it assumes the normal reset state.
Interrupts not being disabled can be a big one, as the application init might enable the device, expecting nothing to happen as interrupts should be globally disabled, but the interrupt fires and enters an ISR that isn’t designed for pre-scheduler use.
Thank you @richard-damon for your response.
The issue has been resolved, the problem was with the value of value of _ebase_address in the linker script.
I have changed its value and the code started working smoothly. Its value basically effects with the vector table placement.
Thank you for reporting back!
If I may ask, what was the ebase_address setting before and after ?
I am programming a similar bootloader on PIC32MZ as well.