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

51–60 of 70 posts

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

#51

Post by girvo »

dognotdog wrote: post #47
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.

We can buy them in 10s at work without too much gnashing of teeth, but the thousands we need is impossible for another 18 months as far as we can tell.

Edited to add: not that it matters now, we moved to a different MCU that we could get larger shipments of, and we’re lucky enough our application of them can be flexible enough to do so!

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

#52

Post by dave78 »

frmdstryr wrote: post #44
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?

Cycle counting is common. Other options exist like a tight loop watching a counter register etc.

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

#53

Post by lebuffon »

Forth is very handy for this kind of new iron startup work.

You can interrogate the hardware interactively for those really thorny problems and confirm your hypotheses immediately. You can write short test scripts and send them via the terminal and/or write and send short Assembler routines and test those interactively. Each routine you define is interactively usable to assist with higher level testing and/or can be further compiled together to make higher level or looping tests.

It's old and it's weird but it's still a good tool for this kind of work. It may mean you only have to enter the top domain of Hell. :-)

https://mecrisp-stellaris-folkdoc.sourceforge.io/flashing-me...

*I have no connection to mecrisp Forth but know it to have a good reputation. It is a a native code compiler with an integrated text interpreter.

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

#54

Post by Taniwha »

jpieper wrote: post #39
Taniwha wrote: post #37

Earlier quoted context omitted.

I think it's more likely that the data needs to cross a clock boundary and multi-clock synchronisation takes time (especially if metastability is potentially an issue) - they way you make it safe is by holding the data you're synchronising stable for multiple clocks and synchronise a strobe signal across the clock boundary and then back again My guess is that the circuit they're using gets confused if you start a sec…

That is possible, although here the consecutive writes were to different ADC peripherals. The ADC peripherals do share some common configuration and triggering, but I believe are otherwise largely independent.

but they're going over the same peripheral bus (from the CPU, and being synchronised to a subsystem with likely the same ADC clock domain - I'd design that hardware once (metastability stuff is notorious for being hard to get right, especially when you are trying to transfer multiple related bits across clock boundaries at the same time, and you want them all to arrive together)

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

#55

Post by jpieper »

Taniwha wrote: post #54
jpieper wrote: post #39

Earlier quoted context omitted.

That is possible, although here the consecutive writes were to different ADC peripherals. The ADC peripherals do share some common configuration and triggering, but I believe are otherwise largely independent.

but they're going over the same peripheral bus (from the CPU, and being synchronised to a subsystem with likely the same ADC clock domain - I'd design that hardware once (metastability stuff is notorious for being hard to get right, especially when you are trying to transfer multiple related bits across clock boundaries at the same time, and you want them all to arrive together)

Yep, there is probably one clock domain for all the ADCs, although there are two different prescalers (one for ADC1/2 and another for 3/4/5).

I could see one of the writes getting lost. In this case though, the ADC enable is what seems to be timing sensitive, however the ADCs always end up enabled properly. It is just that a write that was significantly earlier (the one that sets the prescaler) seems to be lost, despite the register reading back that it was read correctly.

I would expect that if the synchronization failed, reads back would read the wrong value?

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

#56

Post by jpieper »

lebuffon wrote: post #53

Forth is very handy for this kind of new iron startup work. You can interrogate the hardware interactively for those really thorny problems and confirm your hypotheses immediately. You can write short test scripts and send them via the terminal and/or write and send short Assembler routines and test those interactively. Each routine you define is interactively usable to assist with higher level testing and/or can be…

Yeah, I have (maybe slightly fond?) memories of using Forth to develop a tape drive reader and writer for an undergraduate lab project. It is wonderful for some things, although in this case, where the problem was literally which addresses the instructions got assigned to, it is unclear if it would have made anything better.

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

#57

Post by zbrozek »

jpieper wrote: post #45
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.…

Are you out of timers? IIRC the STM32 series typically has timer peripherals that can be configured as encoder inputs.

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

#58

Post by the__alchemist »

dognotdog wrote: post #47
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.

Good to know! I've been trying to get hold of certain H7 and G4 variants in a specific footprint. Family and footprint are a hard requirement, but not too picky otherwise. Checking it out.

Of note regarding the one you linked - great find; looks like that Octopart link was bad! I actually have some 491s, and they're great, except that the OSS firmware I'm using them with for this project doesn't support them. Got my own firmware working on them though.

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

#59

Post by jpieper »

zbrozek wrote: post #57
jpieper wrote: post #45

Earlier quoted context omitted.

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

Are you out of timers? IIRC the STM32 series typically has timer peripherals that can be configured as encoder inputs.

No, but out of pins connected to timers with the appropriate capabilities.

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

#60

Post by duskwuff »

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.

It's also a relatively new part which hasn't developed the kind of demand that leads to counterfeiting yet.

Most of the counterfeiters are targeting well-established old parts like the STM32F103.

Post reply on HN