<story><title>Debugging bare-metal STM32 from the seventh level of hell</title><url>https://jpieper.com/2022/08/05/debugging-bare-metal-stm32-from-the-seventh-level-of-hell/</url></story><parent_chain><item><author>matrix_overload</author><text>&amp;gt;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.&lt;p&gt;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.&lt;p&gt;Could also be flakey power (check your decoupling capacitors) or an outright b0rked chip&amp;#x2F;board.</text></item></parent_chain><comment><author>jpieper</author><text>For what it is worth, the G0&amp;#x2F;4 family is relatively new.  I&amp;#x27;m pretty sure it has unique ADC IP too, since the published errata (which I&amp;#x27;m very familiar with) are different from any other ST chip I know of.&lt;p&gt;The clock should of course have been suspect (as noted in the writeup).  The &amp;quot;bad state&amp;quot; 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.&lt;p&gt;I didn&amp;#x27;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.&lt;p&gt;And while poor decoupling is also a likely problem, I&amp;#x27;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&amp;#x27;ed directly to the ground plane.</text></comment>
<story><title>Debugging bare-metal STM32 from the seventh level of hell</title><url>https://jpieper.com/2022/08/05/debugging-bare-metal-stm32-from-the-seventh-level-of-hell/</url></story><parent_chain><item><author>matrix_overload</author><text>&amp;gt;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.&lt;p&gt;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.&lt;p&gt;Could also be flakey power (check your decoupling capacitors) or an outright b0rked chip&amp;#x2F;board.</text></item></parent_chain><comment><author>jhallenworld</author><text>Maybe, anyway it&amp;#x27;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).</text></comment>