Custom bootloader via Modbus

[DavidNaviaux]

I have a custom design using the STM32G474RBT3 (128kB flash category 3 device) MCU.  In this application, the firmware needs to be updated remotely via the normal communication channels to the board.  In this case, it is Modbus over an RS485 multi-drop network of 76 boards, each with a unique slave address.  When the firmware is to be updated, a special utility can be run on a PC connected to the RS485 network that can be used to update the firmware on all 76 boards in sequence.

I'm about ready to dive into the development of the bootloader and am reviewing the flash memory options which are very confusing to me (as a newbie ARM-Cortex M4 user).  Here are some basic firmware specs:

1. The bootloader uses about 30kB of space and supports USB or RS485 communication.

2. The application firmware requires about 60kB (but it is not completed yet).

Currently, I have the option bits set for a single 128kB bank.  It is not completely clear to me if I can write the flash to the same bank I am executing from.  I may have the option of switching to dual bank mode if my application firmware doesn't grow past 64kB.  I understand that that might simplify updating the firmware.  But if I can do this within a single bank, I would prefer that.

I would appreciate any input.  Thank you.

[TDK]

You can write to the same bank as you're running from. Just need to ensure the bootloader and application live in different flash pages.

If you try to read from the flash bank that you're writing to, itwill cause the cpu to freeze momentarily, but it is only momentary and code will continue after the write is complete.

[DavidNaviaux]

TDK, Thank you.for that information.

I would like to write protect the area that the bootloader code will exist in.  When the MCU is reset, I would like the bootloader code to run then verify that the application code is okay before transferring control to it.  I suppose that i will also need to relocate the interrupt vectors to the application code area.

I have implemented this for two other designs but never for the STM32 MCU.  

I suppose that I will need to get a bit creative with the linker script files.  Is there a good reference or application note that can help me with the script file, with the write protection, or with designing a bootloader for custom applications?

[DavidNaviaux]

TDK,

The product I am working on has 34 bytes of calibration information that would render the product useless if it was corrupted.  For this reason, I need to save those 34 bytes to a write protected section of flash that will never get updated once the product leaves the factory.

Do I have the ability to erase/write to a single double word in flash or do I really need to erase an entire flash page before I can write to it?

Thanks

[TDK · Accepted solution]

> Do I have the ability to erase/write to a single double word in flash or do I really need to erase an entire flash page before I can write to it?

Yes, you really have to erase the entire flash page before you can write to it. If there were a way around it, it wouldn't be a limitation.

There's no time limitation here. you can write to addresses that were erased a long time ago, but you can only write to them once. In that manner you can journal your writes to cut down on flash usage, if that's a concern at all.

[DavidNaviaux]

Thanks TDK,

What I'm mostly concerned about is that there is information that a customer will need to save periodically that is not under our control.  Say, for example, power is lost in the middle of the customer updating the flash and it gets corrupted.  The way I have worked around this problem in the past is to have saved two copies of configuration data, each with an associated CRC.  Then, each time the MCU is reset, it examines the two copies and if required, copies the good one to the bad one and thus recovers.

The issue with the flash solution is that I would have to store the two copies in two different flash pages and that wastes some very critical code space.  However, it does look like for my application, with compiling for size optimization, I do have enough room for the 12kB of flash that will be required to hold the calibration data and the two copies of the configuration data.  The application code is just over 64kB and will grow still a bit so I had to switch to a single bank of 128kB where the flash page size is 4kB.

Thanks again

[TDK]

Yep, if you can't guarantee power stability, using two pages in the manner you described is the only way.

Small external EEPROMs are cheap. Might be worth adding it over the additional code complexity that storing to flash entails.

[Pavel A.]

>will never get updated once the product leaves the factory.

So you have both "write once" calibration data and user configuration data?

The former can be stored in unused part of the last app flash page - because normally the loader does not write the remainder of the last image page. Write two copies if there's enough room.

[DavidNaviaux]

Pavel,

In general "write a few times" calibration data and user configuration that might change several times in a month.

I am too concerned about using the "write once" space because, it is possible that a specific board might need recalibration because of a repair or the firmware updated.

I have it working right now using 3 4kB pages that I have reserved for that purpose, 1 page for the calibration information, and 2 pages for the two copies of the configuration information.

[DavidNaviaux]

TDK,

Yes, I should have used an external EEPROM.  It was an oversight on my part to not realize this MCUs non-volatile storage limitations.  I have two other designs using this MCU coming up shortly.  I have discovered several "gotchas" during the testing of this design that are common anytime I design with a new MCU (especially with ones as complex as this one).  I will address the "gotchas" in those designs. 

You can bet that an EEPROM will get added to the next design. However, I also have to keep two copies in it for the same reasons.

Thanks, David