1
\$\begingroup\$

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.

\$\endgroup\$
  • 2
    \$\begingroup\$ This is exactly why canned code from someone else is a bad idea. It's fine when everything works. When something goes wrong, you're screwed. \$\endgroup\$ – Olin Lathrop Jul 15 '13 at 13:47
  • \$\begingroup\$ Unfortunately it's all time allowed. I'd like to do our own in future, and we judged it as relatively tested from some previous prototypes for other projects. \$\endgroup\$ – njt Jul 15 '13 at 13:53
  • \$\begingroup\$ There's nothing exactly wrong at present with this method, I'd just like to clarify 'why' really, in case of any hidden issues. \$\endgroup\$ – njt Jul 15 '13 at 13:54
4
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ This was the solution, i just totally forgot to update this post when it happened! Thanks! \$\endgroup\$ – njt Feb 18 '14 at 22:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.