I need to design the board that uses STM32L496RG, is able to do some operations, but if needed it has to be able to have FW updated “remotely”. The idea is that the board with the MCU is enclosed, but the access to it would be via some socket (not decided what type yet) in another area.
How can I achieve it if to update the FW I need to change the state of BOOT pins?
So far the idea is to use the RS485 wire, and than the RS485->UART converter but I have no idea how to make it.
So far I have found out that it is possible to change the FW using UART, but I still have no idea how to change the state of BOOT pins.
1
There are multiple ways to update the firmware. However, if the default bootloader does not fulfil your needs, you may have to develop your own bootloader for your specific needs.
General concept
When the MCU resets, it runs the bootloader which checks for a condition to trigger the firmware update (can be an io level, an in memory value, a remote service, etc.). If there is no firmware update to be triggered, then the bootloader starts the application.
In such context, the application must take care of its memory start location, ISR table, and so on in order to ensure it can run properly.
Local fw update
The application saves the new firmware image in a temporary (yet somehow persistent) location, sets the memory flag to tell the bootloader to update, then resets.
The bootloader verifies the image consistency (with some sort of CRC or other mechanism), erases and programs the application’s flash portion, clears the flag, and boots the new application.
In this example, a critical draw back is: if the application does not boot then the system becomes a “bricks” because there is no other mean to upload a new firmware image.
Remote fw update (your case)
Upon fw update request, the application resets and starts the bootloader. Then the bootloader connects to some web service to check whether an update is pending, erases the flash and installs the firmware as it downloads.
Note the “some web service” condition. You do not have remote access to the GPIO to operate a remote update request.
This scenario is more robust to faulty firmware image since the bootloader can always update the system. However, it requires more code to be installed (device drivers, network stack, etc.) and thus reduces the available flash size for the application image ..
NOTE You can think of the bootloader as a side application which its sole purpose is to update and boot the main application.
NOTE There are ways to ensure the images and system consistency (crc, dual memory bank, etc.) but this answer does not focus on this aspect.