Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Debugging bare-metal STM32 from the seventh level of hell

jpieper.com

Post reply on HN
Print view View original

41–50 of 70 posts

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

#41

Post by varispeed »

throw827474737 wrote: post #30
varispeed wrote: post #20

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 alo…

It is a small business, one guy does EE the other does SE.

Their model was to buy parts as they are needed depending on order volume (JIT).

Now with the shortages it is not possible. You can calculate how many orders you may get within a year and place a back order for these parts. 1000 MCUs alone is like £20k. They were looking at spending £50k total and facing no income at all until the parts arrive.

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

#42

Post by seidleroni »

the__alchemist wrote: post #2

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...

Getting samples of G4's was pretty easy. Since its a fairly new part, there was a large stock that distributors had for engineering samples. The story is very different for things like the F5/F7's and even getting small sample volumes is very hard.

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

#43

Post by markrages »

bradfa wrote: post #40

Tangent: reading this, all I could think was "you're allocating memory in a motor controller?!?" and then "you're using interrupts in a motor controller!?!". Surely the bug write up was good and it is interesting, but all of the actual hard real time systems I've ever seen or talked to engineers who actually worked on them always avoided interrupts and never allocate memory. Both of these activities in hard real time…

The "standard" motor control setup for FOC is to do the ADC measurement synchronously with the PWM, to sample the current while the low-side switch is closed. Then the flux angles and voltages are computed immediately afterwards, and the PWM duty updated for the next cycle. This all happens in the interrupt, in a very hard real-time system -- start missing interrupts and all hell breaks loose.

PWM is run as fast as you can get away with, 20 kHz minimum (human hearing). The controller spends maybe 80% of itw time in interrupt context, leaving main context for tasks that are not time-sensitive.

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

#44

Post by frmdstryr »

bradfa wrote: post #40

Tangent: reading this, all I could think was "you're allocating memory in a motor controller?!?" and then "you're using interrupts in a motor controller!?!". Surely the bug write up was good and it is interesting, but all of the actual hard real time systems I've ever seen or talked to engineers who actually worked on them always avoided interrupts and never allocate memory. Both of these activities in hard real time…

> always avoided interrupts

I'm curious... how does one achieve precise timing without interrupts?

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

#45

Post by jpieper »

bradfa wrote: post #40

Tangent: reading this, all I could think was "you're allocating memory in a motor controller?!?" and then "you're using interrupts in a motor controller!?!". Surely the bug write up was good and it is interesting, but all of the actual hard real time systems I've ever seen or talked to engineers who actually worked on them always avoided interrupts and never allocate memory. Both of these activities in hard real time…

Here "allocation" is all fixed size things pulled from a fixed size buffer at startup. Technically malloc is compiled in the firmware, but it isn't used for anything but some C++ runtime initialization confirmed with debugger breakpoints. The only dynamic use of memory is the call stack, which has only fixed size local variables and limited depth recursion.

Similarly, "interrupts" may not mean what you are thinking. The highest priority interrupt is one attached to the PWM timer that operates the primary control loop that operates in interrupt context. As of a few months ago this is slightly more complicated to accommodate some "soft" quadrature decoding, but the principle is still the same that all motor control is performed in an interrupt context and nearly nothing else is.

Everything else, like CAN communication, is performed in a polling manner in the "main" loop.

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

#46

Post by jcelerier »

bradfa wrote: post #40

Tangent: reading this, all I could think was "you're allocating memory in a motor controller?!?" and then "you're using interrupts in a motor controller!?!". Surely the bug write up was good and it is interesting, but all of the actual hard real time systems I've ever seen or talked to engineers who actually worked on them always avoided interrupts and never allocate memory. Both of these activities in hard real time…

> Tangent: reading this, all I could think was "you're allocating memory in a motor controller?!?" and then "you're using interrupts in a motor controller!?!".

to be fair, that STM32 from what I can see benchmarks at 550 in CoreMark which puts it above a Pentium I, it's not like they're using a 8051 or a PIC16F... there's likely a lot of spare CPU time

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

#47

Post by dognotdog »

the__alchemist wrote: post #2

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...

I just bought 10 off digikey last week, to have some prototyping stock. Looks like they still got some: https://www.digikey.com/en/products/detail/stmicroelectronic...

Octopart, etc haven't been able to accurately track inventory through this disruption.

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

#48

Post by fxtentacle »

jpieper wrote: post #21
fxtentacle wrote: post #18

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.

Agree, I've never had bad experiences with Mouser.

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

#49

Post by exikyut »

jpieper wrote: post #29
matrix_overload wrote: post #6

>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…

I wonder if it would be possible to create a test jig that turns on the ADCs all at once then samples data through them (perhaps just from a function generator)?
Post reply on HN