ST embedded bootloader revovery

[uer166]

I'm implementing a FW update scheme using the ST embedded UART bootloader. There are a lot of issues/hurdles but there is one I can't quite see through yet: the bootloader auto-detects the baud rate based on a 0x7F byte sent which creates the pulse and it figures out what baud rate you're talking to it at.

The issue is: if, for whatever reason, that byte is not 0x7F (say if updater is out of sync with the updatee), or it's malformed, the bootloader mis-configures the baud rate, at which point the bootloader gets stuck forever waiting for bytes at the wrong baud rate. This is not recoverable for me since there's no way to reset MCU, and I don't believe there's a watchdog or anything in the BL. What do?

[andersm]

The MCU will wait until it can read an 0x7F byte. If something else is received, it'll just keep waiting. For the baud rate to be misconfigured, you'd have to send something that aliases to a valid 0x7F frame.

[uer166]

That means that from my quick testing, a very large percentage of bytes sent at 9600 baud alias to 0x7F in higher frequencies. I presume because the bootloader baud rate goes so high..

Or maybe it's because their code is dumb and simply measures time between 2 low-pulses and uses that time to calculate.

[andersm]

At least according to the documentation, the rate is calculated based on the duration of the frame. Have you verified that you can get ST's own programming tool, or eg. stm32flash to work?

One gotcha with the ROM bootloader is that if your device supports multiple bootloading interfaces, traffic on the other ones may cause the bootloader to choose the wrong one.

[uer166]

Yes stm32flash works (after adding a memory map of a newer device since ST isn't interested in supporting their own software), and I've developed some test code for reading/writing memory as well. That's sort of how these issues came about, and I realized that if the bootloader ever gets into that state, the whole expensive device is bricked with no way out except maybe full disassembly and tapping into the reset line of the offending micro.

I think I will add a GPIO connection from the updater to the reset line of the updatee to mitigate this, giving full control. More level shifters, more hardware, sigh. This is for a long battery stack, a 60-MCU daisy chain basically. So even one extra capacitor becomes 60 extra capacitors.

[abyrvalg]

Dump & post that internal ROM and I’ll tell what’s going on there exactly and which conditions hang it.
Btw, if the flash space permits it, you can just design your own bootloader adapted to your application (use whatever baudrate, WDT, status LEDs, method of entry etc).

[nctnico]

IMHO it is a good idea to add an external watchdog chip to the MCU. You can connect the watch-dog timer reset pin to a gpio and the transmit data to the UART. It won't reset when the firmware isn't running or when there is external communication. Making your own firmware update system is also a good alternative. At least you'll have full control over the update process.

Still I don't get why you'd need 60 MCUs in a battery stack. There are dedicated BMS chips which don't require a whole bunch of microcontrollers.

[uer166]

Still I don't get why you'd need 60 MCUs in a battery stack. There are dedicated BMS chips which don't require a whole bunch of microcontrollers.

The dedicated BMS chips do exist, but so far in my studies the cost per cell of those BMSs doesn't make sense in this system. With the custom one micro per cell solution, I can do around $0.8 per cell easily with the STM32, and maybe $0.4 with a bunch of elbow grease and a Nuvoton micro or whatever else exists with a 12-bit ADC and a bandgap reference.

If an off-the-shelf BMS IC exists that is stackable, can achieve that cost, I will surely switch over, it would be much easier that way. I've checked Maxim's, TI's, and LT's portfolio, and a ~12s stackable IC costs around $15 in volume, not including ancillaries. I am confident in this architecture though, because a fellow engineer designed decent size automotive battery packs with this architecture (including the FW update process I'm building now), so at least it is doable.

[uer166]

Btw, if the flash space permits it, you can just design your own bootloader adapted to your application (use whatever baudrate, WDT, status LEDs, method of entry etc).

That is a solution. It's just man-hours, risk, and also then the micros need to be pre-programmed before assembly somehow, there will be no space for 60 JTAG headers. The beauty of the embedded BL is that it comes straight from factory chips.

I'll get to posting the ROM dump in a few days... I don't think anyone has reverse engineered it yet.

[uer166]

Unrelated, but since I had so much trouble making the ST UART flashing tool work, here's the solution for newer chips for anyone else that comes upon the problem:

If your micro doesn't appear in the Flash Loader Demonstrator thing dropdown after it successfully connects, means its' memory map doesn't exist in "C:\Program Files (x86)\STMicroelectronics\Software\Flash Loader Demo\Map\" directory where the flash loader lives. For the STM32L011, file attached. Need to add that to the directory and it will appar and be fully functional then. Have to rename it to .STmap and add it to the above directory. It's a modified file from another STM32L0 with changes to the device ID and the flash/EEPROM mapping.



Keywords: STM32L011 STM32L01 serial UART bootloader loader STM32 Flash loader demonstrator FLASHER-STM32

[nctnico]

Still I don't get why you'd need 60 MCUs in a battery stack. There are dedicated BMS chips which don't require a whole bunch of microcontrollers.

The dedicated BMS chips do exist, but so far in my studies the cost per cell of those BMSs doesn't make sense in this system. With the custom one micro per cell solution, I can do around $0.8 per cell easily with the STM32, and maybe $0.4 with a bunch of elbow grease and a Nuvoton micro or whatever else exists with a 12-bit ADC and a bandgap reference.

If an off-the-shelf BMS IC exists that is stackable, can achieve that cost, I will surely switch over, it would be much easier that way. I've checked Maxim's, TI's, and LT's portfolio, and a ~12s stackable IC costs around $15 in volume, not including ancillaries. I am confident in this architecture though, because a fellow engineer designed decent size automotive battery packs with this architecture (including the FW update process I'm building now), so at least it is doable.

Makes sense but lower channel count BMS chips (just a random pick: BQ76PL536APAPR stackable to 192 cells in series) cost less per cell. There is an optimum somewhere but I'm probably not telling you anything new here.

However, you'd have to sell a huge number of these batteries to recoup the NRE costs. Also: what is the cost for the Li-ion cell(s) versus the electronics? And then there are safety and risk management issues to consider. Your approach is interesting but BMS chips have several safety features designed in or at least make it easy to implement a BMS which is safe without depending too much on software. A large chunk of the hard work (and learning from mistakes) to design a safe battery pack has already been done if you use a standard BMS chip. One of my customers is a high volume Li-ion battery manufacturer; all their BMSes use standard cell management chips. Not wanting to start a discussion; I'm just offering some food for thought.

[uer166]

Appreciate the concerns, some answers to your qs: It will be a fully isolated pack, with single fault FMEA compliance so that one bad bandgap reference or bad micro can't kill the pack or create an unsafe situation. It will have an independent isolation monitor from the B- and B+ to the aluminum chassis as well. It will be tolerant to individual cell connection going open, so that the BMS doesn't fail catastrophically (this is not implemented even in commercial BMSs, like Orion).

I'm not selling any, this is a fun project, and if there is demand then I will think about it.

The cells are 18650s at $2 per cell in my volume, so a $1 per cell BMS is 50% of the cost or so. It's 60s1p, so each 18650 is serviced individually. This also helps with internal short immunity: if a cell shorts, BMS safely shuts down, instead of unlimited current being dumped from adjacent cells, which is a nice free safety bonus.

The BQ76PL536APAPR is $7 in my volume, and it's about $1 per cell just the IC. My solution is potentially around $0.4 for all components per cell. I admit, I missed this one (I was only looking at 12s+ chips), and it's by far the closest one to the MCU solution so far  so I will seriously consider this one, thanks for the tip. The internal isolation is super great. I'll need 10 of these per pack, but no biggie.

[nctnico]

It would be interesting to do some cost calculations on a boost-converter powered from a 6s10p pack versus using many cells in series  With 60 cells in series the load needs to be able to handle approx. 150V to 260V DC.

[uer166]

Ah, now we digging deep in the requirements. I'm almost 100% sure a boost to required V would be cheaper than proposed solution. Problem is, efficiency for the on-board 600W or so pure sine 120V inverter. Boost+inverter stage is ~94% efficiency if you try really hard. Just the inverter alone is 98% if you also try really hard. Heatsink is 3X smaller in the direct inverter version! 36W vs. 12W power dissipation. And since another thing is passive only cooling, suddenly the extra giant BMS starts making sense. Most of the cost I anticipate will be the bigly CNC case/heatsink anyway, so a 2X reduction in fin height/number would bring overall cost down.

So, given the fact that a HV pack is needed, I'm trying to come up with the cheapest possible BMS solution for that.

[abyrvalg]

Got two ST ROM dumps recently - STM32F103C and STM8L151K6, both implements a pretty similar baud rate detection algo:

Code: [Select]

activate IWDG watchdog
wait until RxD=1 - this is idle state
wait until RxD=0 - this is leading edge of start bit
wait until RxD=1 - this is leading edge of bit 0 of 0x7F sync byte
start timer
wait until RxD=0 - this is trailing edge of bit 6 of 0x7F
get elapsed time - this is duration of 7 '1' bits of 0x7F
set UART bit period =  time / 7
So:
- baudrate detection itself can't hang (IWDG will reset the CPU)
- the sync byte is not checked to be 0x7F, any trash containing 1010 sequence will be accepted
- after detection the algo proceeds to RxByte functions kicking the IWDG endlessly until something is received

[Siwastaja]

there will be no space for 60 JTAG headers.

Solution: small pads and a pogo pin programming jig. Some mechanical engineering required to make it easy&quick to use, yet provide accurate registration so the pad size can be minimized; for one-off, consider it a learning experiment. For production, it pays itself back quickly.

Off-the-shelf BMS chip is not a silver bullet, some are buggy or outright dangerous; some come with misleading application notes. I have good experience on rolling my own like you are doing (one MCU per cell, BOM was around $0.50 per cell on small scale Digikey prices) but of course nctnico is right there are risks involved.

[uer166]

- after detection the algo proceeds to RxByte functions kicking the IWDG endlessly until something is received

Thank you for the confirmation, this would be an unrecoverable fault in my original design. If I go with the home-rolled design I will also daisy chain the reset lines so that an MCU can reset the N+1 MCU directly. In my quick tests this mis-detection happens constantly.