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

[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?

[johu]

Will read the article later...

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

[crasbe]

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

[janosch]

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

[johu]

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.

[crasbe]

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

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

[janosch]

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