Posted on September 08, 2016 at 15:31Bootloaders have a place but aren't always necessary. We've had this debate where I work. Our solution is to put as much as possible into the application, and only use a custom bootloader if necessary.
We use 'L152 and 'L475 parts. All our boards have a JTAG, so we don't need to use the system bootloader to load code. We do over-the-air firmware updates through radios, so the system bootloader doesn't help at all there either.
For the 'L475, which has a dual flash bank with hardware address remapping we don't use a bootloader. Firmware updates load into the alternate bank, address is remapped and booted to new image. All the download and verification logic is in the app, so the update process shares the code needed for data transfers, no extra work on our part to handle image downloads. That reduces development costs.
For the 'L152 we do have a small, 1KB bootloader that transfers flash bank 2 to flash bank 1 if EEPROM flags are set. The image is downloaded as part of the app, which keeps the bootloader very simple. The 'L152 also has dual flash banks but doesn't have the address remap option, so we have to transfer the image to the first bank in order to start it.
For hobbyist, yeah, the system bootloader saves the cost of a JTAG, but how do you debug the code if you don't have a JTAG pod? There are very cheap JTAGs, saving a few dollars by using the loader wastes a lot of time and guarantees programmer frustration at guessing what went wrong without a clue where to start.
For commercial use we prefer to download the initial firmware image on the production line through JTAG, faster and more reliable. We disable the system bootloader in hardware, though we do keep a jumper option just in case. We have stringent requirements to verify the integrity of downloaded images in the field and can't rely on the system bootloader protocol. Our equipment is at remote locations and very expensive to service; we can't risk bricking it with a bad or incomplete update.
Jack Peacock
