Debugging bare-metal STM32 from the seventh level of hell
jpieper.com
jpieper.com
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.
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.
https://github.com/mjbots/moteus/blob/dcb900c92ffd5d5c8f5405...
Notably, the datasheet is largely silent on interactions between different ADCs during initialization.
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.
My guess is that the circuit they're using gets confused if you start a second write when the first is not yet done
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?
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...
I've recently started looking at them. The SDK is nice except that they chose to use CMake. I designed it out:
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
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) was not fully usable without interfering with the firmware.
for what? What sort of possible thing would you need to do on a c-m0 that needs more than 128K of CODE!?
in NOR flash???
:cringe:
What seems like a huge amount of Flash disappears quickly.
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.
Octopart, etc haven't been able to accurately track inventory through this disruption.
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!
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.
I also have custom flight controller firmware in Rust that's running fine on G491, but Betaflight needs 47x or 48x.
No luck on getting H7s.
PWM is run as fast as you can get away with, 20 kHz minimum (human hearing). The controller spends maybe 80% of itw time in interrupt context, leaving main context for tasks that are not time-sensitive.
I'm curious... how does one achieve precise timing without interrupts?
Similarly, "interrupts" may not mean what you are thinking. The highest priority interrupt is one attached to the PWM timer that operates the primary control loop that operates in interrupt context. As of a few months ago this is slightly more complicated to accommodate some "soft" quadrature decoding, but the principle is still the same that all motor control is performed in an interrupt context and nearly nothing else is.
Everything else, like CAN communication, is performed in a polling manner in the "main" loop.
to be fair, that STM32 from what I can see benchmarks at 550 in CoreMark which puts it above a Pentium I, it's not like they're using a 8051 or a PIC16F... there's likely a lot of spare CPU time
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.
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 huge back-orders, but small business can't tie up that kind of sums of money for unknown period of time. He placed orders for that MCU over a year ago and distributors still tell the production is delayed. Meanwhile Chinese don't seem to be short of supply and are milking the desperate market.
Seems like a state intervention would be welcome here.
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.
It's not ideal, probably it will create further delays, but it would put small business on the level playing field with the big corporations when it comes to orders.
The criteria for eligibility may be difficult to define too, so that fraud is minimised.
Maybe such surge of demand could incentivise MCU manufacturers to secure more fab capacity.
State could also make scalping illegal. For instance buying MCUs with a sole purpose to hold on them and then resell at inflated price would be illegal. This could be done by setting maximum margin someone could ask, that should be no higher than Mouser or Digikey have. So anyone selling MCUs at 10x the price would have them confiscated and get fined. Foreign online stores that facilitate such sellers like Aliexpress would risk being sanctioned and banned.
The price-controls idea would create shortages, at least locally; Mouser and Digi-Key, prohibited from allocating scarce parts to those with more willingness to pay, would allocate them according to other criteria, such as customers with the largest established volume. Companies in other countries would have a major edge because they'd have access to distributors who weren't at risk of having their stock confiscated. The upshot would be that companies in whatever country instituted those price controls would be unable to compete on the global market because they couldn't buy on Aliexpress. (I've seen this kind of thing a lot up close and personal because I live in Argentina.)
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
Their model was to buy parts as they are needed depending on order volume (JIT).
Now with the shortages it is not possible. You can calculate how many orders you may get within a year and place a back order for these parts. 1000 MCUs alone is like £20k. They were looking at spending £50k total and facing no income at all until the parts arrive.
After I finally admitted defeat and called my TI (Texas Instruments) support engineer, he said, "oh, that's a brand new part. You guys are actually only the second company we've sold it to. Thanks for the bug report, but we just discovered it last week so it'll be fixed in the next rev."
Hmm? Ok, it may be the clock or something else subtle but if they tell you to wait...
I sure do love and miss doing this kind of engineering work.
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.
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.
Most of the counterfeiters are targeting well-established old parts like the STM32F103.