Firmware Update

[Tedico]

We have implemented a custom tool, which transfers a hex firmware file via USB DFU protocol to the control. While testing we had several problems sending the firmware to the control.

First we extract the memory model out of the descriptor infromations of the DFU device. Then we erase all eraseable memory blocks and afterwards we write the firmware information to the specific addresses.

Afterwards we use the CubeProgrammer to read out the whole memory information. Then we upload the Firmeware via the CubeProgrammer and also read out the whole memory information. We could find out that the hex file which we are sending consists of 3 different Memory parts which we send differently to the control. But the CubeProgrammer seems to merge the first to blocks and send them as one memory block sequential to the usb device. We also found out that the end of the first block is 4 bytes earlier than the start of the second block and that the CubeProgramme fills this "empty block" with FF bytes.

So after we have adapted our software to merge this to blocks and fill the space between the blocks with FF it's know working. So my question is, why is this space filled up with FF? Should it also work if we don't fill up the space?

The firmware update is know working, but we aren't sure if the space between the blocks is fix at 4 bytes or may could increase. We just have to be sure that the firmware update is working with every firmeware file and not only randomly.

Many thanks in advance.

Kind Regards,

Benjamin

[Tesla DeLorean]

For most STM32 the erased state of FLASH is 0xFF (cells all high). The L1 as I recall it's 0x00

The minimum write width can vary, from 32 to 64-bit or more, this is for efficiency reasons, the decode/fetch of the arrays is quite slow, and the wider width distributes that cost, and either goes into the cache, ART accelerator, or prefetch queue. The wider width can also accommodate ECC check bits, you don't see these, but need to get written by the FLASH controller in a singular pass.

Unwritten memory will have cells all high after the erase.

[Tesla DeLorean]

.BIN files can't be sparse. .HEX, .ELF and .DFU can be, as they can describe regions by address and size. The DFU tool can also fold unused space.

The HEX2DFU tool that I built ensures 8-byte / 64-bit alignment