Live data from Hacker News

Debugging bare-metal STM32 from the seventh level of hell

jpieper.com

21–30 of 70 posts

Re: Debugging bare-metal STM32 from the seventh level of hell

#21

Most likely, the author is using counterfeit hardware. I haven't seen authentic ones in stock anytime this year. And bugs in rare edge cases is precisely what I would expect from a price-conscious copy.

Surprisingly, it is almost certainly genuine. These particular chips likely came from a batch delivered in April of 2021 from Mouser, who isn't known for their shoddy sourcing practices.

Re: Debugging bare-metal STM32 from the seventh level of hell

#22

Yikes! That sounds frustrating. As the article concluded with, the way forward appears at the end; ST adding an errata for this. The elephant in the room: How is the author getting STM32 G4s? I've been F5ing this every day with no luck for months: https://octopart.com/search?q=stm32g4+ceu&currency=USD&specs...

Order far in advance....? These particular chips arrived more than a year ago.

But yes, the shortage is hitting hard here too. The last tray I received was one year ago, after which all orders have been unfulfilled.

Re: Debugging bare-metal STM32 from the seventh level of hell

#23

Earlier quoted context omitted.

But balanced against basically unlimited flash size. Many of my projects end up having an external SPI-flash for one reason or another anyway. Another similar chip is the i.MX rt1020 from NXP (except Cortex-M7 and way more expensive). The one gotcha was that there was only one QSPI-flash controller even though there were two ports. It meant that the extra port (which we assumed would be available during architecture)…

> Many of my projects end up having an external SPI-flash for one reason or another anyway. for what? What sort of possible thing would you need to do on a c-m0 that needs more than 128K of CODE!?

Wait, wasn't there some guy who got an entire Linux system booting on a microcontroller that's smaller than a Cortex-M0? https://dmitry.gr/?r=05.Projects&proj=07.%20Linux%20on%208bi...

Re: Debugging bare-metal STM32 from the seventh level of hell

#24

How did they manage to get STM32s? My friend's small business had to close, because key MCU is not available anywhere and Chinese sell it for the price of the end product. Makes business no longer viable. He spent over a month designing board for another MCU that was available at the time, but as soon as he was ready to produce more the alternative was gone too. It's like chasing own tail. Big corporations can post h…

Probably the beginning of that month of designing would have been a better time to order the microcontrollers than the end of it. The answer to "how did jpieper get STM32s" is "he ordered them from Mouser in early 02021": https://news.ycombinator.com/item?id=32383312

What kind of state intervention are you thinking of? I spent some time trying to think of a state policy that would reduce the risk that small businesses would lose access to parts crucial to their products, rather than increasing it, but I couldn't think of one.

Re: Debugging bare-metal STM32 from the seventh level of hell

#25
post #16

Earlier quoted context omitted.

There's plenty of STM32 of any flavor in China. Alibaba is a good source. There may be fakes though, but reputable resellers (pay attention to reviews and tenure) normally sell genuine chips.

Are fakes of lesser quality? How do you tell fake from genuine?

I've gotten some Blue Pills with (properly labeled) CKS32s on them, which might be of lesser quality, but I've also seen people reporting getting Blue Pills with (properly labeled) GD32s, which are higher quality than the ST part, at least in the sense that they run successfully at higher clock speeds. (I couldn't tell you if they have more problems turning on many peripherals at close-together times, or if they have more noise on their ADCs, or something.)

Re: Debugging bare-metal STM32 from the seventh level of hell

#26

How did they manage to get STM32s? My friend's small business had to close, because key MCU is not available anywhere and Chinese sell it for the price of the end product. Makes business no longer viable. He spent over a month designing board for another MCU that was available at the time, but as soon as he was ready to produce more the alternative was gone too. It's like chasing own tail. Big corporations can post h…

From my experience there’s nothing to do but order in advance with as large of a stack of cash as you can manage and pray. It’s hardly worth writing code these days until you have supply sorted. Bugging your suppliers frequently can help, it’s how we got enough STM32s for development, but for production quantities it’s a waiting game. Upper management at my company balked at tying up capital for a large chip order about a year ago. Guess what? Now we’re paying even more for fewer chips to keep the lines up.

Re: Debugging bare-metal STM32 from the seventh level of hell

#27
The initial state of doubting the test fixtures (healthy skepticism!) highlights that it's very useful to keep a few known-good hw specimens over time, so that when you get a new batch that fails, you can test your test equipment against the older, known good hardware. Also swap firmware versions back and forth on old/new hw and see how behavior/metrics change.

Re: Debugging bare-metal STM32 from the seventh level of hell

#28

>It seems that the ADCs on the STM32G4 do not like to be turned on in rapid succession, and if they do, bad things can happen like having the prescaler flipped to a different value without it showing in the corresponding register. This sounds very, VERY much like an incorrectly configured clock where some of the peripherals would end up with a clock frequency slightly above what they were designed for. Will work 99%…

Or it was just faulty firmware and he did hit the (almost) correct conclusion:

ADEN bit on g4:

"Note: The software is allowed to set ADEN only when all bits of ADC_CR registers are 0 (ADCAL = 0, JADSTART = 0, ADSTART = 0, ADSTP = 0, ADDIS = 0 and ADEN = 0) except for bit ADVREGEN which must be 1 (and the software must have wait for the startup time of the voltage regulator"

No errata needed, it's clearly stated that you cannot just set ADEN without waiting for certain other conditions.

Re: Debugging bare-metal STM32 from the seventh level of hell

#29

>It seems that the ADCs on the STM32G4 do not like to be turned on in rapid succession, and if they do, bad things can happen like having the prescaler flipped to a different value without it showing in the corresponding register. This sounds very, VERY much like an incorrectly configured clock where some of the peripherals would end up with a clock frequency slightly above what they were designed for. Will work 99%…

For what it is worth, the G0/4 family is relatively new. I'm pretty sure it has unique ADC IP too, since the published errata (which I'm very familiar with) are different from any other ST chip I know of.

The clock should of course have been suspect (as noted in the writeup). The "bad state" in this problem was basically indistinguishable from running the ADC at too high a clock rate. In fact, the default rate when I first encountered this problem does ever so slightly overclock the ADC. It is rated for 60MHz for single ADC operation, but only 26MHz for multiple ADCs. The firmware used to run the ADCs at ~28MHz, purposefully going a tiny bit above that.

I didn't include it in the writeup since it was somewhat of a diversion, but this particular problem occurred even with the ADCs configured to be clocked slower. As mentioned, I think that their clock configuration became mis-set as a result of the underlying problem.

And while poor decoupling is also a likely problem, I'm 95% sure it is about as good as it can get. A high quality cap of appropriate size is immediately next to the chip on every supply pin with vias directly to the ground plane. This is a low pin count QFN part, so the only ground on the chip is the center pad, which is also via'ed directly to the ground plane.

Re: Debugging bare-metal STM32 from the seventh level of hell

#30

How did they manage to get STM32s? My friend's small business had to close, because key MCU is not available anywhere and Chinese sell it for the price of the end product. Makes business no longer viable. He spent over a month designing board for another MCU that was available at the time, but as soon as he was ready to produce more the alternative was gone too. It's like chasing own tail. Big corporations can post h…

> Seems like a state intervention would be welcome here.

And that should look like how??

> can't tie up that kind of sums of money for unknown period of time.

Seriously curious now, must have a real cash cow with little development or huge volume?

Because what my company would have needed to pay for the MCU to put in stock for say 3 years is still dwarfed by one developers salary for a year (and the software team alone is varying 5-10, not including electro engineers or all other kinds). So in the aftermath just ridiculous to not have invested that money for the stock when the demand and MCU was clear (and for us it was at that point back already).

Also, nothing would have been better than tieing money that way, it could have made more profit by also becoming a broker now, lol :D

Post reply on HN