Upgrading a section of firmware using IAP

[himanshu]

Posted on March 25, 2011 at 07:57

Upgrading a section of firmware using IAP

[Tesla DeLorean]

Posted on May 17, 2011 at 14:29

As ColdWeather points out your minimum blocking size for erase is the page size of the device you are using, nominally 1 or 2K.

Your finest write granularity is 16-bits (half word aligned).

With suitable de-blocking techniques you can write/replace anything you want. Just remember to do so smartly, so you maximize the amount of data being written, and minimize the erase cycles, limited as they are.

Also, be aware that writing to flash, while running from flash, will stall processor execution. Many flash devices don't even permit this, but on the STM32 you can, it will limit your ability to service the serial port in a timely manner, resulting in overruns. So don't write half-words as you received them, get a whole block, and use a method that uses flow-control techniques. Such a method would be XMODEM, it is a VERY simple protocol, but is extremely good for such tasks. ST has YMODEM examples, which isn't nearly as good because unless you can use CTS/RTS it is going to keep pushing a stream of data at you.

YMODEM is designed for error-correcting modems with hardware flow control. The ST implementation, last I looked, was a half assed cut-n-paste of some open source example on the web. The cut down version won't handle errors well, and basically assumes everything is going to work fine. Which is great when it does, but the real world isn't that kind.

Suggest also you down load the PM0042 document, which talks about flashing, and look at ST's serial flashing tools which include source and talk to the Boot Loader ROM.

[ColdWeather]

Posted on May 17, 2011 at 14:29

The question is too general. The solution depends upon, what tools you are gonna use.

For instance you can use ''STM Flash Loader Demonstration'' program via USART along with the embedded boot loader placed in the so called ''system memory'' of the MCU. You prepare then HEX files that contain the part of the flash to be actualized, and load it by means of tools mentioned.

The second way is to use DFUSE if your MCU supports USB.

The third possibility is to write your own boot loader as a part of your firmware and to use your own tools.

Anyway you should take care of the allocation of the parts of your firmware: the part(s) to be actualized has/have to be aligned to the flash pages.

[Andrew Neil]

Posted on May 17, 2011 at 14:29

''XMODEM, it is a VERY simple protocol, but is extremely good for such tasks''

 

Indeed.

''YMODEM ... isn't nearly as good because unless you can use CTS/RTS it is going to keep pushing a stream of data at you''

Not so: YMODEM is basically the same as XMODEM (identical block structure and ACK/NAK sequence), but with some extra initial exchanges to allow multi-file transfers.

http://www.textfiles.com/programming/ymodem.txt

''YMODEM is designed for error-correcting modems with hardware flow control.''

 

 

You're thinking of

Z

MODEM there, perhaps? Or, maybe, YMODEM-G ?

''The ST implementation, last I looked, was a half assed...''

 

You flatter it!

''The cut down version won't handle errors well''

IIRC, it does no error checking whatsoever!

''the real world isn't that kind''

Indeed!

[Tesla DeLorean]

Posted on May 17, 2011 at 14:29

Or, maybe, YMODEM-G ?

Probably YMODEM-G, as that'd be the only variant more efficient than a fairly generic ''XMODEM 1K w/CRC16'', because it's not positively acknowledging every packet, and waiting around.

I don't see ZMODEM being a good candidate for this task.

[trevor23]

Posted on May 17, 2011 at 14:29

One of the big reasons you might use YMODEM over XMODEM is that XMODEM pads the last packet (with 0x1A). A good YMODEM implementation will remove the padding as the file length is known (in XMODEM the file length is not known). This usually isn't an issue for firmware (padding does not matter) but for other files it almost always is. Before you start jumping to the defence of XMODEM  I use it often as it is smaller than YMODEM which is good for a small bootloader, I'm just making people aware of a potential issue. In my case my firmware files always have a header with length and CRC so I don't care whether XMODEM or YMOPDEM is used, and I don't care if packets are ''checksumed/CRCed'' as I can remove padding and do my own integrity check.

[Andrew Neil]

Posted on May 17, 2011 at 14:29

''I don't see ZMODEM being a good candidate for this task''

 

Agreed.