Hello,
I have to design a device which has a STM32L152VD as main micro-controller. The user should be able to update the firmware using a GUI software from RS232. There should be a secure process to update the firmware. For example after verifying a password by micro-controller and there should be always a backup firmware to replace if the updating process failed. Should I use a second micro-controller and a flash memory to do this or is it possible to use the same MCU to handle it?
These are certainly things that can be readily done. If you want to keep a backup, having an external SPI flash device may be a way of holding that, and staging the update image. The main way to do this with just the processor is to have a small bootloader (few KB) that can flash the remainder of the device and is not erased. This would prevent you bricking the device in the field.
Thanks. I googled "STM32 Boot Loader" and find many valuable information as well as app notes in the web. How ever I also need to know that if there are any points I should consider for developing a windows application for downloading the firmware to the microcontroller? Is it just simply sending the built Hex file to the micro-controller through UART?
If you implement a boot loader that supports a standard transfer protocol (like x-modem or similar), then you can use a standard transfer program on Windows to send the new binary.
It's common to not send hex files, but instead create a binary file with a small block first or last that contains some checksum and some magic marker so the boot loader knows the user doesn't try to send a garbage file.
So the boot loader receives and writes to secondary flash storage. Then it verifies the complete transfer and if ok erases and overwrites the application. If power is lost, then the boot loader checks that the application isn't completely flashed, and restarts the programming.
Most of the work in Windows is controlling the user experience and dealing with errors, retries, picking a COM port, etc.
I wouldn't deal with .HEX files, as they are usually at least 2.5x bigger than binary data, so much more efficient to send in binary, encrypted if you prefer. You can implement any protocol you choose, I tend to prefer a XMODEM 1K/CRC, which is small and robust for IAP
Thanks. How should we tell the MCU what the communication protocol (XMODEM,etc.) we start to use for loading application using bootloader? also, Do we have limitation on code size when we wish to load to MCU using boot loader in comparison with SWDIO,Jtag,etc. ?
You would have to write the code to implement the loader protocols of your choice.
Boot Loader is a generic term, if you want to interact with the ROM based System Loader the you'll need to use its documented protocol, or use it as a method to download your own loader code into RAM and transfer control to that.
The System Loader isn't going to provide you with any encryption or security. It can access all the FLASH memory in the device.
If you code your own loader, with its own features, this will take up some FLASH, which you will ideally not erase or overwrite.
You should review ISP (In System Programming), and IAP (In Application Programming), the former is the ROM Loader, the latter provides you with significantly more control, and the pins/interfaces used.
If you want to own the experience at both ends you'll need to write the code on the micro-controller, and the Windows/Linux GUI applications.
ST's Flash Loader Demonstrator and DFU applications aren't the most user-friendly tools, and are design primarily for the developer/engineering community.