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.
Debugging bare-metal STM32 from the seventh level of hell
21–30 of 70 posts
Re: Debugging bare-metal STM32 from the seventh level of hell
#22Yikes! 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...
But yes, the shortage is hitting hard here too. The last tray I received was one year ago, after which all orders have been unfulfilled.
Re: Debugging bare-metal STM32 from the seventh level of hell
#23Earlier quoted context omitted.
But balanced against basically unlimited flash size. Many of my projects end up having an external SPI-flash for one reason or another anyway. Another similar chip is the i.MX rt1020 from NXP (except Cortex-M7 and way more expensive). The one gotcha was that there was only one QSPI-flash controller even though there were two ports. It meant that the extra port (which we assumed would be available during architecture)…
> Many of my projects end up having an external SPI-flash for one reason or another anyway. for what? What sort of possible thing would you need to do on a c-m0 that needs more than 128K of CODE!?
Re: Debugging bare-metal STM32 from the seventh level of hell
#24How 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…
What kind of state intervention are you thinking of? I spent some time trying to think of a state policy that would reduce the risk that small businesses would lose access to parts crucial to their products, rather than increasing it, but I couldn't think of one.
Re: Debugging bare-metal STM32 from the seventh level of hell
#25Earlier quoted context omitted.
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.
Are fakes of lesser quality? How do you tell fake from genuine?
Re: Debugging bare-metal STM32 from the seventh level of hell
#26How 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…
Re: Debugging bare-metal STM32 from the seventh level of hell
#27Re: Debugging bare-metal STM32 from the seventh level of hell
#28>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%…
ADEN bit on g4:
"Note: The software is allowed to set ADEN only when all bits of ADC_CR registers are 0 (ADCAL = 0, JADSTART = 0, ADSTART = 0, ADSTP = 0, ADDIS = 0 and ADEN = 0) except for bit ADVREGEN which must be 1 (and the software must have wait for the startup time of the voltage regulator"
No errata needed, it's clearly stated that you cannot just set ADEN without waiting for certain other conditions.
Re: Debugging bare-metal STM32 from the seventh level of hell
#29>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%…
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 first encountered this problem does ever so slightly overclock the ADC. It is rated for 60MHz for single ADC operation, but only 26MHz for multiple ADCs. The firmware used to run the ADCs at ~28MHz, purposefully going a tiny bit above that.
I didn't include it in the writeup since it was somewhat of a diversion, but this particular problem occurred even with the ADCs configured to be clocked slower. As mentioned, I think that their clock configuration became mis-set as a result of the underlying problem.
And while poor decoupling is also a likely problem, I'm 95% sure it is about as good as it can get. A high quality cap of appropriate size is immediately next to the chip on every supply pin with vias directly to the ground plane. This is a low pin count QFN part, so the only ground on the chip is the center pad, which is also via'ed directly to the ground plane.
Re: Debugging bare-metal STM32 from the seventh level of hell
#30How 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…
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 alone is varying 5-10, not including electro engineers or all other kinds). So in the aftermath just ridiculous to not have invested that money for the stock when the demand and MCU was clear (and for us it was at that point back already).
Also, nothing would have been better than tieing money that way, it could have made more profit by also becoming a broker now, lol :D