I have an embedded system with a PIC24 host which I've just finished off the code for, and have noticed some odd changes to the way my bootloader works but without actually changing anything low level enough to affect this.
I've been using the Microchip USB HID bootloader for a while now, and usually it's quite literally plug it in, load hex and press go. Recently I've had to ensure the config bits are being written also, but my config bits haven't changed in the BL or the main app in months (verified by our git history).
If I write the hex onto the device without programming the config bits also, it either becomes totally unresponsive or acts like there is no app and always defaults into the BL.
It works fine with the config bits being programmed, but I can see how this is a bad move for any production units in the case of a field upgrade, even if it is a long shot at bricking the unit.
The only major change I've noticed is we switched to a large code model in xc16-gcc, but I was under the impression this would only flag the compiler various things about locality of variables etc., and not change any memory allocations.
Has anyone seen this behaviour before? It may very well be something we've missed in the datasheets.
Best Answer
The Microchip bootloader code likely is erasing the entire Flash region before programming. If you don't program the config bits before reset, they will be left at 0xFF which is quite unlikely what you wanted.
Either modify the bootloader to avoid erasing the final page of Flash, or make sure you re-apply the necessary config after erasing.