Firmware upgrade over CAN bus with STM32?

[Red_Micro]

How challenging is to update a firmware over CAN bus in STM32? I guess I need to write a custom bootloader, right? Any recommendations?

[DEV001]

STM has an app note which may help. https://www.st.com/resource/en/application_note/cd00264321-can-protocol-used-in-the-stm32-bootloader-stmicroelectronics.pdf

Canprog may be of use if you want to test flashing your board and the source is available on Github.

https://pypi.org/project/canprog/

https://github.com/marcinbor85/can-prog

[Siwastaja]

First look at what internal bootloader is available. Notoriously, ST has completely fucked up the CAN bootloader in newest devices so it's not backward-compatible and requires CAN FD interface which is utterly silly.

Custom bootloader is almost always the best way to go forward, anyway. It doesn't need to be a "bootloader" in the strict sense of the word; it can be a part of application that erases and rewrites flash, you can call it flasher. The difference is, a bootloader runs before the "actual" application and may do things like allowing to reflash one section of flash while retaining working application in another.

Writing a simple flasher isn't rocket science:
* Make sure all functions are located in RAM (just SRAM or ITCM if available)
* Make sure compiler doesn't generate library calls like memcpy behind your back which would reside in flash. You see, if such function is called during flashing, the flash is already erased or written with a new content where the memcpy is in a different place so it obviously crashes.
* You can add something like NOCROSSREFS(.text_itcm .text); in your linker script to verify that does not happen
* Obviously you can use the already existing CAN functions but if you do so, remember to make sure they are in RAM, too...
* If you can fit the whole firmware image in RAM, it's a good idea to receive all of it first to reduce the risk of anything going wrong. I like to add a CRC check before starting to actually flash.
* The flash operation itself is fairly simple and described in the reference manual. Varies a bit device-by-device, but in general:
* Unlock the flash by writing magic unlock values in the lock register
* Erase flash by writing some erase command bit and polling a status bit until done
* Enable write access with some command bit
* Write the content as normal memory access operations; may need to poll a status bit after each write
* Disable write access
* Reset the CPU

Protocol design is up to you which is the best part. If you keep it very simple, a minimalistic flasher can be less than 100 lines of code total.

[Red_Micro]

First look at what internal bootloader is available. Notoriously, ST has completely fucked up the CAN bootloader in newest devices so it's not backward-compatible and requires CAN FD interface which is utterly silly.

So you would use ST devices with the older CAN controller Bx? Or the devices specified in this document for example? https://www.st.com/resource/en/application_note/cd00264321-can-protocol-used-in-the-stm32-bootloader-stmicroelectronics.pdf

[Siwastaja]

Well I wouldn't choose the device primarily based on what factory bootloaders are available... But if you have many equivalent choices and one has the CAN bootloader which is actually supported by the typical non-FD CAN adapters and have multitude of flashing software available, then use it.

It would be nice to do initial flashing through CAN using the factory bootloader but you still need access to BOOT0 pin so it won't never be the same as your own bootloader/flasher which can be truly a part of your application with absolutely no special hardware (such as a jumper that you need to physically place), enabling wireless firmware update for example.

[mjs]

Check out Feaser OpenBLT. It's really good and rock solid, available both GPL and commercial license.

[S. Petrukhin]

Abstract question: do you still plan to use STM32, despite the price increase of 10-20 times and complete absence from the market?

[Siwastaja]

Abstract question: do you still plan to use STM32, despite the price increase of 10-20 times and complete absence from the market?

Chip shortage applies to basically all manufacturers and tomorrow something else may have worse availability. If something is well available during global shortage of everything, that's likely a sign that they don't have many customers; for example, RS232 level converters in DIP packages have good stock because no one uses them.

OTOH, large and successful players like ST have good chances of being present after the crisis as well...

There's no complete absence, in STM32 parts we use lead times through distributors are seemingly around 3-6 months which is actually what was guaranteed to begin with under normal conditions. We have seen no significant price increase, $6 chips are still around $6. If you talk about grey market dealers, well no shit, 10-20x price increase applies to any part which has shortage, that's their business.

[Siwastaja]

Note, when I say "custom bootloader" is the way to go above, I mean that as opposed to performing all software updates using ST's factory bootloader or through the SWD. It doesn't need to be written from scratch by you, use an existing one like OpenBLT if you wish. I haven't bothered because writing one from scratch is not too much work (this isn't a TCP/IP stack level of complexity) and then I get exactly what I want without investing time first to try out existing solutions which may or may not do what I need.

I would choose based on tooling available, because if you do it from scratch, you are going to need to write your tooling as well. So if you find OpenBLT, for example, have good programming tools for multiple platforms and find people are familiar with them, that's reason enough to just use OpenBLT.

[AndyC_772]

It's certainly true that STM32 availability is particularly poor right now, but "10-20 times" is nonsense.

I've spent the last few weeks helping customers manage a number of component availability problems. In some cases it's just been logistics, contacting potential alternative suppliers on their behalf.

In others, it's been designing new products based around whichever parts are actually in stock and available to purchase right now, rather than the 'ideal' best trade-off between cost and capability that I might choose during more 'normal' times. It's much better to design in a part that costs, say, £7.50 and is in stock today, than one which would normally be £5 but is out of stock, even if that means there's memory capacity that will never be used.

STM32 parts are particularly good for having pin-to-pin compatibility across different parts in the range. If you can't buy the part you originally designed in, it's definitely worth looking to see if there's a part which has more memory, more internal peripherals, or even an upgraded core. Chances are, if there is, it'll be 100% binary compatible.

[JOEBOBSICLE]

I've done bootloaders quite a fair few times: I'd implement the following commands:

Program word
Erase page
Calculate CRC
Read bootloader version
Read hardware version
Jump to application code

This enough to have a fairly reliable bootloader that's flexible enough to run on any MCU. I'd stick message counters on each message as it makes development easier

[AndyC_772]

In my experience the hardest part is memory management, ie. making sure that every part of your bootloader and application code is in the specific place you need it to be. Any bootloader will need to be customised in some way to suit the Flash structure of your MCU, ie. locations, sector sizes, minimum erasable or programmable block sizes, vector locations, and so on.

I find linker scripts particularly cryptic, so I particularly appreciate the fact that my preferred IDE (Rowley CrossWorks) creates them on-the-fly from a much more readable XML format. Check it out if you haven't already; the hobbyist licence in particular is stupidly cheap for what you get.

Custom bootloader is almost always the best way to go forward, anyway. It doesn't need to be a "bootloader" in the strict sense of the word; it can be a part of application that erases and rewrites flash, you can call it flasher.

+1 for this. I have a project which migrated from this model to a completely separate bootloader, in the traditional sense of the word, but I'm not completely sure the separate model is actually "better" in every way. The integrated 'flasher' was easier to develop and has some intrinsic benefits, not the least of which is that there's only one binary to keep track of.

[S. Petrukhin]

It's certainly true that STM32 availability is particularly poor right now, but "10-20 times" is nonsense.

Sorry for continuing the topic in a different sense, but I bought on LCSC STM32F103VET6 a year ago for $4.5 and their stock was several thousand. Now I was offered it for $79. This is completely stupid. Mouser and Farnell don't have these chips at all. The same goes for the high F4xx models. I still have a reserve of time and there is a backup option with the Russian equivalent, but the situation is frightening.

[Siwastaja]

Everybody knows this, the situation is what it is and because it affects all manufacturers, it makes no sense basing future purchase decisions on this. STM32 has a fairly good track record of being available and being a safe choice. OTOH, I can imagine some oddball component being well available now but then disappear after 2 years due to no one buying it (which would be the reason it is well available now). If you base your long-term decision on the current situation, you are likely to do wrong choices.

[peter-h]

32F4 prices are fine, deliveries are being quoted for Sep/Oct 2021 (1k+). And you can buy 10-20 ex stock for 10 quid. Forget the hysteria; the bubble will burst just like they always do, 6 months later. Some "normal" components are getting hard to get also but they tend to be cheap.