Page 1 of 1

Non-maskable Interrupts in Bootloader

PostPosted: Wed Mar 07, 2018 5:14 pm
by MagicSmoke

I have implemented a bootloader on dsPIC33E (dsPIC33EP512GM604) in line with the Microchip application notes AN1157 for remapping of interrupt vectors from boot to OFP using a jump table (AN1157 option B). Everything works as expected and I am able to update my main application over CAN.

However, I am not quite sure what to do with the non-maskable interrupts (oscillator, stack, DMAC, exceptions etc.). When the main application is not present there is nothing to jump to, so could potentially try and execute garbage. I have ensured that the jump table area is filled with zeros (stop) initially (i.e. after boot has been flashed), but this doesn't protect for partial updates where the main application has been erased.

Any advice on what to do with those interrupts? Maintain them in the bootloader? Map them to a common area which could be updated (doesn't help with partial erase)?


Re: Non-maskable Interrupts in Bootloader

PostPosted: Thu Mar 08, 2018 3:09 am
by AussieSusan
I would have thought that either the bootloader or the application would be running at any point in time - the only other alternative is that the CPU is not running at all.
You may need to 1) not write to those entries in the IVT so that the bootloader will receive them, 2) have the bootloader be "smart" and overwrite those IVT entries if the app doesn't or 3) realise that the default is always a "goto 0" and so have the bootloader intercept that vector and handle it appropriately.
(I won't mention the 4th alternative which is to move to another MCU that has an alternative IVT for the bootloader.)

Re: Non-maskable Interrupts in Bootloader

PostPosted: Thu Mar 08, 2018 9:07 am
by MagicSmoke
Thanks for the reply. Regarding your 4th alternative...I am porting from a dsPIC33F which had that very option, but the processor was selected by hardware team ahead of any software involvement, so I am stuck with it now! ;-)

Option 2) might be interesting. I think I read that the EZBL from microchip has ISRs which determine if boot of application are running and handle/branch as appropriate, I will go and read up on that.

At the moment the handling of the exceptions will be the same, but in the future the application may store fault data or take a different action in the event of one of those interrupts. SO allowing the handler to be updated as part of the application is a good idea (difficult access to device once it is built into the product).