Download and update firmware and firmware

Question

When working in an embedded system, there are two cases. The embedded system has limited resources, such as an ARM Cortex M0 Microcontroller with a 12-megapixel flash.

Case 1: General use of a function / module for bootloader and firmware: To prevent duplicate code, the bootloader and firmware may need to use the same module and function. Otherwise, the same code will be included both in the firmware and in the bootloader twice. We can prevent this by specifying the address of the function and calling this function by calling the functions at the addresses. This is one of the solutions.

Is there any smart method to ensure the common use of functions?

Case 2: Sometimes we need to update the firmware. One of the duties of the bootloader is to update the firmware. We can easily update the firmware by overwriting the old one.

As we have seen, two cases can be implemented separately. But when we merge them, some problems arise.

Question: The loader is usually static objects, but the firmware can be changed. Therefore, common functions are usually located in bootloaders. But when we need to update a common module / function, how can we do this?

What are common or smart approaches , which bootloader, embedded systems, embedded systems? Also for limited resources.

For discrete common modules / functions Can one or more additional areas solve this problem. Firmware, bootloader and library (new area)?

I want to learn common approaches. Is there a paper, book, and source on advanced firmware management?

thanks

Answer 1

If you share the code between your bootloader and your firmware, then your bootloader will use this code when the application space starts blinking. To prevent this condition, you must sacrifice the ability to update the common code, otherwise your bootloader will crash.

With only a 12k flash, it's pretty ambitious to expect the bootloader application and the main application to match. You might want to write the bootloader to the assembly (sigh!). Some parts of the Cortex M0 (such as the NXP LPC11xx family) have an optional boot ROM that stores some useful features and helps alleviate some memory limitations.

Answer 2

Your question has the correct formulation of the problem - you cannot get your cake and eat it. Or:
1. You are busy with a small amount of memory and do not include the firmware update logic in the bootloader (for example, the bootloader can simply check the CRC image of the application, etc., but not more complicated). Here you can share features to save space. OR
2. The bootloader has firmware update functionality. Here you should have common functions compiled both in the application and in the bootloader. The shared functions should be small - maybe not big overhead, but you need the space that it will take - if you don't have one, you need more memory.
It is not possible to share functionality and reliably perform firmware update from the bootloader.

Answer 3

In light of the ongoing discussion about security during the firmware upgrade process . I would like to add the following explanations: Code exchange between the bootloader and the application will open another door for a potential attack, so you really want to avoid this.

The bootloader part is the part that you really don’t want to change, it should be as static as possible. If the bootloader is broken, field updates become almost impossible, or at least unsafe.

Having said that, you can use a different approach. You can create a maintenance mode for your device. This mode opens the JTAG interface and provides direct memory access. A technician can apply the update.

Now you only need to "activate" the service mode. The following may work: Use the UART interface for activation communication.

• The service system sends its own identifier and requests a service mode through UART
• The maintenance system identifier, a random number, and a unique system identifier are sent back to the service system.
• The service system sends this identification sequence to your certification server.
• If the unique identifier of the system and the identifier of the service system are correct, the server will create a signature of the received information and send it back to the service system.
• Now your system will receive a signature through UART
• Your system verifies the signature against the previously sent public key identification string stored during production.
• Successful verification mode supported

To add security, you definitely want to put some effort into the service identifier, following a similar pattern. The identifier should mainly depend on the MAC address or other unique identifier of the equipment and its signature. The identifier must be created in a safe environment during the production process of the maintenance system. The unique identifier of the equipment must be something visible to the outside world, so the server can really check whether the received ID matches the service system that interacts with the server.

All this setting will give you a secure firmware update without a bootloader. To have reliable firmware updates, a common understanding is that you need an authentication system based on asymmetric encryption such as RSA. If you still need a confirmation code, then the above will exchange a bootloader that can receive updates using the simple UART interface, saving some resources in this process.

Is this what you were looking for?

The commercial bootloader in my experience uses 4 to 8k flash memory depending on the flash algorithm and several other things. I adhere to the same supplier throughout my career, so this may differ from your experience.

Optimized for embedded systems, the digital signature system uses approximately 4.5 kB of flash memory (for example, see https://www.segger.com/emlib-emsecure.html here) and no more RAM than the stack.

You see that 12k is really very low in terms of having a system that can be reliably updated in the field. And even more so if you want the system to be updated using the bootloader.