2
\$\begingroup\$

I am using a microcontroller with flash memory partitioned into two areas (i.e) Primary & Secondary. When a remote firmware upgrade is done, I am writing the received binary file over Ethernet to the secondary (inactive) partition of the flash. If the received and calculated CRC matches, the boot loader will copy the latest firmware from secondary to primary partition.

How to handle the situation in which the size of the binary file exceeds the size of either primary or secondary partition of the flash?

\$\endgroup\$
  • 2
    \$\begingroup\$ A big question to consider is what state you need the product to be in after receipt of a bad update file: still fully operational? Or merely still able to accept a good firmware update (without resort to special tools such as a jtag adapter). If the later, you don't need to keep a complete firmware in reserve, you just need to keep enough of a bootloader to load a new update. \$\endgroup\$ – Chris Stratton Feb 25 '13 at 16:15
7
\$\begingroup\$

1) Buy more flash.

2) If it's just over the limit, make the code smaller (configure compiler options for minimum size, remove duplicate strings, check for dead code and unused functions)

3) Compress the firmware while downloading. Then the staging area can be smaller than the primary partition, which can then be made larger.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ Bootload first a program just for boot loading that is very small and does not need much memory and then bootload the rest? We have done that before but I think the question is more focused on external flash, not the micro's internal flash. ie. Intermediate program that will free more flash memory, if possible. Worth adding to your answer since writing an answer that does not cover 3/4 of the useful Ideas I have. \$\endgroup\$ – Kortuk Feb 25 '13 at 14:56
  • \$\begingroup\$ I would almost give a -1 for "compress it", as the available flash usually outstrips the available RAM in a micro, and uncompressing-and-burning on the fly seems fraught with risk. Plus the compression routine will make the firmware even bigger... \$\endgroup\$ – John U Feb 25 '13 at 15:12
  • \$\begingroup\$ Question doesn't specify a size; gzip compression probably is worth it if you have megabytes of firmware, or much of it is lookup tables or text. You can also do a decompress, CRC and discard operation first, so you've checked CRCs on the compressed and decompressed versions, before burning on the fly. \$\endgroup\$ – pjc50 Feb 25 '13 at 15:56
3
\$\begingroup\$

You can't, at least not while keeping with your memory allocation scheme that you outlined. I have used this same sheme a few times myself, but it does have the characteristic that somehow somewhere you need local storage for two images of the app.

Write more compact code, use a bigger processor, or add external non-volatile memory.

| improve this answer | |
\$\endgroup\$

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.