ROM Bootloader - only responds with 0xA5

[JBill.10]

I have two boards, both with the G473.

I am using the ROM bootloader on SPI1.

On one board, the bootloader works.  On the other, it only responds with 0xA5 during the initialization sequence.

The MCU can program and run if I load it through the SWD port.

I have checked the SPI signals, both digital and analog, they look great.  The MCU pins are firmly soldered to the board.  The other board works.  My code works.  If you can actually get the bootloader to synchronize, it works.

I have gone through every forum post I can find, and it is sounding like there is a possible consensus that the ST bootloader is bugged and will sometimes initialize the wrong interface.  Is that... really true?  It selects the wrong interface and all of these people are having problems with it?  Can any one from ST talk about this?  This sounds like a really serious problem if true!  What else could it be?

AN2606 says the G473 will init the pins on the USART and I2C interfaces to pullups - so the fact I have those unconnected shouldn't be a problem.  Nothing is happening on those pins.  The other SPI port's NSS is always high, so that interface can't be enabled (unless the bootloader has a bug!).

[Tesla DeLorean]

>>I have gone through every forum post I can find, and it is sounding like there is a possible consensus that the ST bootloader is bugged and will sometimes initialize the wrong interface.

Could you perhaps cite a few salient ones to your case? It would help a lot to pin down specifics.

The UART ones have problems if connected to other devices that squawk at boot time, like GPS/GNSS receivers, as this is seen as a interaction, and the System Loader is trying to measure the timing of the 0x7F 8E1 data pattern to auto-baud. If those other pins are silent it shouldn't cause a problem.

Other board? Does it have an MCU from the same batch? Not sure if you can readily identify with an ST-LINK if the STM32G4 share the same loader version.

Would suggest opening an online support request. https://ols.st.com/s/

[JBill.10]

Both boards built at the same time, so it is likely the MCUs are the same batch, but yeah I'll need to confirm that with the debugger (haven't yet).

I don't have anything connected to the unused interfaces that would cause any noise or traffic.  They are either floating (and the ROM loader docs indicate they initialize pulls on those pins), or they are driven to a DC voltage.

The story gets much weirder.  I grounded a bunch of the other comms pins, just to rule them out.  Bootloader starts working.  I then start ungrounding the pins to try and find which one is the issue.  I do this until I run out of pins, board is back to stock configuration, and it still works.

Until it doesn't.  Strange.

So then I hit it with hot air.  Works again.  Cools off, stops working.

I even ran my sync routine in a loop and watched it in the debugger: hot air on, works, cool off, stops working.

So, heating the MCU makes the bootloader work.  Running it at room temp, it will fail.

I have 6 more boards coming in later today, so I can try those as well and get more of a statistical sampling.
This kind of behavior is unfortunately a very bright red flag.  I don't know how the bootloader is coded (since ST won't let us see it) but this kind of behavior is indicative of an improperly initialized interface that is triggering on analog silicon behavior - exactly the sort of thing firmware engineering is supposed to contain.  I write a lot of bootloaders and this is not a normal problem to have if you set things up properly.  I'd love to hear from ST how this is supposed to work - and more importantly, answer the most important question I have: "Is there any way I can possibly trust this bootloader to work, given what I have seen here?"

[TDK]

It's indicative of a poor hardware design or other hardware issues. Cold solder joint is a strong possibility.

You can blame the bootloader if you want, but it won't solve your issue. Bootloader is in ROM. You can read out the code and verify it's the same on the working chip vs not working.

Buy a known good board such as a Nucleo and try it on there.

Maybe not the message you wanted--easier to blame others--but it's the suggestion with a technical basis. Stay objective. Monitor NRST to see if BOR is getting triggered, see if VCAP is stable, etc. Multimeter won't cut it.

[JBill.10]

The statistical sampling on the next round of boards should rule out assembly issues.  It is certainly very strange.

Given the number of posts that have this problem (along with the poor docs that require several undocumented workarounds, such as the need to poll for ack), along with the poor interface selection, it does sound like the bootloader has issues.  I'll be able to confirm that on Monday.  I can absolutely blame the bootloader if it is the bootloader's fault, and that will absolutely solve my issue: I will roll my own and integrate an extra firmware step in my test system.  It was just going to be more convenient to use the one already in ROM that we are all paying for, but that was on the assumption the ROM loader is actually reliable.

It's really not about it being easier to blame others, it is about finding the root cause and seeing that in general ST has not been very helpful to the other people who have the same problem.  They haven't given me confidence and this absolutely has to work every time - we use this in the field.  This is not a complicated hardware interface to get right and I've already confirmed that the MCU runs fine if loaded with app firmware by hand and the SPI interface I am using works fine - both of my MCUs can talk to each other.  The other pins are static or floating.  The docs don't say what to do with them and say the bootloader enables its own pulls.  This is exactly the sort of thing good firmware is supposed to handle and it doesn't look like it is.

Sometimes it actually is a ROM bug, just like sometimes it actually is a compiler bug.  It isn't until it is, and once it is, you have a major problem that might not have a clear solution (in one case we had to change compiler versions, it just generated the wrong instruction sequence in a corner case and GCC didn't have a bugfix for it yet).  You do this long enough and these kinds of corner cases come up.

[JBill.10 · Accepted solution]

Well, I've now spent days on this, and I am walking away with nothing.

The problem wasn't isolated to a specific board and it is extremely intermittent.  I checked for any bootloader pins that weren't held at a defined voltage and patched those, no luck there.  I tried doing register dumps to figure out which interface comes up, couldn't glean much from that (got that idea from an ST youtube video, they don't even bother to do app notes anymore I guess).  This really shouldn't be this complicated and we just cannot have fussy, unreliable, buggy behavior in a bootloader.  I've gone through post after post after post with similar issues and ST just does not care.

To every other hapless engineer who finds their way here:

Give up and write your own bootloader.  It's not worth the effort to debug ST's mess, they won't help you, there appears to be a real problem they don't want to talk about, and in the time you waste you could have just written your own and moved on.  Learn from my (and many others here) mistake.  I have written plenty of my own bootloaders and never had issues like this in my own code.  You can all do better than this.