Debugging bare-metal STM32 from the seventh level of hell
1–10 of 70 posts
Re: Debugging bare-metal STM32 from the seventh level of hell
#2Yikes! 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¤cy=USD&specs...
Re: Debugging bare-metal STM32 from the seventh level of hell
#3Yikes! 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¤cy=USD&specs...
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.
Re: Debugging bare-metal STM32 from the seventh level of hell
#4STM32s are actually very nice things to debug by the standards of the embedded scene.
At least 1 set of stm32 cube tools will be always working.
It's not uncommon for microcontroller vendors to not to provide any tooling at all, and just say "Use JTAG" without any further explanations.
And then JTAG may, or may not work. Or only work on some decade old 3rd party IDE + 3rd party USB (or even RS232...) JTAG debugger + pre sp2 win xp version combo.
Re: Debugging bare-metal STM32 from the seventh level of hell
#5Yikes! 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¤cy=USD&specs...
If you can use Cortex-M0+ (so not likely for this project, BLDC where you want floating point), maybe think about RP2040 (Raspberry Pi Pico chip)? More than 100K of them in stock at Digikey, only $1 each... But they come in only one package type, and use external flash (an advantage, IMHO).
I've recently started looking at them. The SDK is nice except that they chose to use CMake. I designed it out:
Re: Debugging bare-metal STM32 from the seventh level of hell
#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% of the time and will give you hell for the remaining 1%. Much more likely than stumbling upon an undiscovered errata in a fairly popular device family with 10+ years of history.
Could also be flakey power (check your decoupling capacitors) or an outright b0rked chip/board.
Re: Debugging bare-metal STM32 from the seventh level of hell
#7Yikes! 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¤cy=USD&specs...
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.
Thanks for the tip! Will check that out. Worth taking the risk.
Re: Debugging bare-metal STM32 from the seventh level of hell
#8>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%…
[deleted]
Re: Debugging bare-metal STM32 from the seventh level of hell
#9>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%…
Maybe, anyway it's worth opening a case with ST support. I found a bug in STM32L0 a few years ago, and they did help (they found a software workaround which was not yet documented- had to do with waking up from deep sleep).
Re: Debugging bare-metal STM32 from the seventh level of hell
#10Yikes! 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¤cy=USD&specs...
If you can use Cortex-M0+ (so not likely for this project, BLDC where you want floating point), maybe think about RP2040 (Raspberry Pi Pico chip)? More than 100K of them in stock at Digikey, only $1 each... But they come in only one package type, and use external flash (an advantage, IMHO). I've recently started looking at them. The SDK is nice except that they chose to use CMake. I designed it out: https://github.co…
> an advantage, IMHO
it isn't
An extra chip means higher cost to produce & assemble board, larger board size, more pins wasted on this nonsense, most fast-edge signals to route, more passives, extra risk to handle for one extra chip being out of stock, and it is much easier to extract firmware than even from a "protected" stm32
Also wasting RAM (and power for it) on code, or random (between high and very high) latency of XIP from SPI flash