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

Post Reply
User avatar
janosch
Posts: 306
Joined: Tue Jun 30, 2020 9:23 am
Location: London, UK
Has thanked: 67 times
Been thanked: 54 times
Contact:

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

Post by janosch »

Article:
https://jpieper.com/2022/08/05/debuggin ... l-of-hell/

Discussion on Hacker News:
https://news.ycombinator.com/item?id=32381448

Read that this morning, thought some of the techniques he applied were curious. His result as well, if he only had internalised the STM32 documentation and learned everything by heart this wouldn't have happened to him ;)

By the way, given that STM32F103 availabilty is difficult and looks to remain so, what will future OI and EVBMW boards use most likely?

What are others using for their VCU/Firmware?
User avatar
johu
Site Admin
Posts: 5684
Joined: Thu Nov 08, 2018 10:52 pm
Location: Kassel/Germany
Has thanked: 153 times
Been thanked: 960 times
Contact:

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

Post by johu »

Will read the article later...
janosch wrote: Mon Aug 08, 2022 9:57 am By the way, given that STM32F103 availabilty is difficult and looks to remain so, what will future OI and EVBMW boards use most likely?
While all distributors are out of them, jlcpcb has them back in stock at just $7.5. So not spending much thought on it now. Not sure what the latest jellybean replacement could be
Support R/D and forum on Patreon: https://patreon.com/openinverter - Subscribe on odysee: https://odysee.com/@openinverter:9
User avatar
crasbe
Posts: 234
Joined: Mon Jul 08, 2019 5:18 pm
Location: Germany
Has thanked: 43 times
Been thanked: 97 times

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

Post by crasbe »

johu wrote: Mon Aug 08, 2022 11:30 am
janosch wrote: Mon Aug 08, 2022 9:57 am By the way, given that STM32F103 availabilty is difficult and looks to remain so, what will future OI and EVBMW boards use most likely?
While all distributors are out of them, jlcpcb has them back in stock at just $7.5. So not spending much thought on it now. Not sure what the latest jellybean replacement could be
I think the only jellybean replacement would be the RPi2040, but I don't think a switch to that would be reasonable. That would mean going away from the whole (very viable!) STM32 ecosystem to a single product ecosystem without substitutions.


I'll read the article later as well. I've been through bare-metal STM32 debugging hell as well, but with the STM32F030, which has very limited debugging capabilities compared to other STM32s, because in case of a fault it just jumps to the HardFault vector without information where the fault occured. The STM32F0 series doesn't have the more sophisticated Fault vectors the other STM32s have.

In the end the fault I was chasing was me forgetting to add a waitstate to the Flash access. When working above 24MHz, you need an additional waitstate. The nasty thing is though, that the program *SOMETIMES* works. Some areas of the flash work without the additional waitstates, but not all and not always. So sometimes the program ran for hours and after a recompile with insignificant changes, it crashed instantly.
Took me a couple of days to find it... in the end I should've read the documentation more carefully as well :D
User avatar
janosch
Posts: 306
Joined: Tue Jun 30, 2020 9:23 am
Location: London, UK
Has thanked: 67 times
Been thanked: 54 times
Contact:

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

Post by janosch »

crasbe wrote: Mon Aug 08, 2022 11:45 am , but with the STM32F030, which has very limited debugging capabilities compared to other STM32s, because in case of a fault it just jumps to the HardFault vector without information where the fault occured.
That sounds like fun.
No callstack no nothing? stm32-template/libopencm3 jumps into blocking_handler but unless the stack is corrupted gdb backtrace can always tell you where you came from.
User avatar
johu
Site Admin
Posts: 5684
Joined: Thu Nov 08, 2018 10:52 pm
Location: Kassel/Germany
Has thanked: 153 times
Been thanked: 960 times
Contact:

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

Post by johu »

crasbe wrote: Mon Aug 08, 2022 11:45 am I think the only jellybean replacement would be the RPi2040, but I don't think a switch to that would be reasonable. That would mean going away from the whole (very viable!) STM32 ecosystem to a single product ecosystem without substitutions.
Interesting part nonetheless. I don't think there should be a "switch" to a new component but rather new processors could be supported just as new inverters are added from time to time. Meaning to say the firmware should stay unified with the target processor being selected at compile time.

Work is being done on a TI version of openinverter. Let's see if that can eventually be integrated into the main branch.

Back on topic I have always been too lazy to carry out methodical (work harder, not smarder ;) ) debugging as described, like cross checking every register and stuff. The datasheet always had the answer when read 10 times over, so far. Knock on wood.
Support R/D and forum on Patreon: https://patreon.com/openinverter - Subscribe on odysee: https://odysee.com/@openinverter:9
User avatar
crasbe
Posts: 234
Joined: Mon Jul 08, 2019 5:18 pm
Location: Germany
Has thanked: 43 times
Been thanked: 97 times

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

Post by crasbe »

janosch wrote: Mon Aug 08, 2022 12:21 pm
crasbe wrote: Mon Aug 08, 2022 11:45 am , but with the STM32F030, which has very limited debugging capabilities compared to other STM32s, because in case of a fault it just jumps to the HardFault vector without information where the fault occured.
That sounds like fun.
No callstack no nothing? stm32-template/libopencm3 jumps into blocking_handler but unless the stack is corrupted gdb backtrace can always tell you where you came from.
I'm not sure anymore (it's been nearly 3 years), but the issue was that once the crash happened, it looked like a wild crash the the microcontroller just jumping randomly through the memory space until it hit something "illegal".
User avatar
catphish
Posts: 954
Joined: Fri Oct 08, 2021 11:02 pm
Location: Dorset, UK
Has thanked: 93 times
Been thanked: 179 times

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

Post by catphish »

As far as I can tell, STM32, including those with CAN are coming back into stock now. I switched my projects to RP2040 out of necessity for a while, but will definitely return to STM32 now they're available.

Hopefully at some point a newer STM32 will become the "standard" STM32 and replace the F103, as there are MUCH better chips available in the lineup these days. In a way, I see the huge diversity of STM32 as a disadvantage as it can be confusing, hence why people are still using the F103.
User avatar
janosch
Posts: 306
Joined: Tue Jun 30, 2020 9:23 am
Location: London, UK
Has thanked: 67 times
Been thanked: 54 times
Contact:

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

Post by janosch »

Yeah, I didn't realise they were back. In that case I am happy to stick with them ad infimum.
Post Reply