Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Debugging hardware is hard

blog.supermechanical.com

Post reply on HN
Print view View original

21–30 of 32 posts

Re: Debugging hardware is hard

#21

Post by readmodifywrite »

barbegal wrote: post #3

Someone else had a similar issue 6 years ago https://electronics.stackexchange.com/questions/334012/hsi-a... It sounds like the sampling clock frequency is not what is expected (but that's quite easy to check based on the transmitted signal so I'm quite confused) UARTs are nice if you are constrained on pins but SPI is always a safer bet where you don't have the necessary high accuracy clocks.

My guess is that the receiver clock glitches in some way when the MSI auto calibration runs, but it never showed up on the transmitter (and the device on the other side of the connection has never had a reception issue).

I ended up disabling the auto cal feature during a UART reception and then turning it back on when the reception is done.

SPI is definitely better as far as clocking, but MCU support as a SPI receiver is sometimes a lot less convenient to deal with.

A lot of UARTs have a synchronous mode which adds a dedicated clock signal - I've used that before out to a couple MHz.

In this application though, I'm only running 1 MHz so I really didn't think I should need a separate clock (and, it turns out, still don't).

Re: Debugging hardware is hard

#22

Post by readmodifywrite »

userbinator wrote: post #17

I couldn’t find anything in the docs or on the Internet about why this might happen with the autocal, and there’s nothing that details exactly how it works either. A quick search found this document on the internal RC oscillator calibration, which explains all you need to know: http://nic.vajn.icu/PDF/STMicro/ARM/STM32F0/STM32F0xx_intern... It is recommended to stop all application activities before the calibration p…

This is a good resource, however, it didn't apply in my situation because it describes the manual calibration process, not the auto-cal (which the F0 probably doesn't even have).

I still haven't come across anything that explains in detail how the auto-cal works and precautions one needs to take when it is running. The reference manual section is something like one paragraph and can be summarized as: "You can turn this on and it will calibrate your clock. You can also turn it off."

If I had to guess, it probably does something similar to the manual process, but just in the MCU logic. It's the lack of detail that got me: I basically ran out of things to try on the UART itself and started looking around at other parts of the chip to see what could at least be indirectly related.

Re: Debugging hardware is hard

#23

Post by readmodifywrite »

upwardbound wrote: post #19

Is it possible that the autocal is in the process of shifting the phase the clock it controls to match the reference clock, and that the user is supposed to wait until that's done before running phase-sensitive operations? I'm unfamiliar with the chip in question, just making guesses or shots in the dark.

It really seems like it has to be something like that. The problem is there is no detail in the docs and no status bits in the chip. There's no way to know when the auto-cal runs.

One of the several things I did to eliminate the problem was to disable the auto-cal during a UART reception (the STM32 is the bus master so it knows when it will be receiving) and re-enable it when it is finished. It absolutely confirmed that is the glitch, but I don't think I'll ever get a true why unless an ST engineer wants to chime in!

Re: Debugging hardware is hard

#25

Post by pajko »

jagraff wrote: post #8
ChrisMarshallNY wrote: post #7

True, dat. My first job, was as a bench tech for an RF/microwave manufacturer (defense). I think that experience made me a much better debugger, when I switched to software. A lot of my work was analog (Spectrum Analyzers, Oscilloscopes, Signal Generators, etc.), but we also did a lot of digital debugging. One of the coolest tools we had, was what was called an "ICE" (In-Circuit Emulator). You yanked out the processo…

Why is it impossible to make an ICE for current processors? Just because they're too complex and/or data exfiltration at speed is too hard?

Other tools made it irrelevant, like boundary scanning on the JTAG bus, the EJTAG interface of the MIPS CPUs, the ETM of ARM chips, and so on. The required adapters are still somewhat pricey, but there are cost-effective solutions for both HW and SW.

Re: Debugging hardware is hard

#26

Post by barbegal »

readmodifywrite wrote: post #21
barbegal wrote: post #3

Someone else had a similar issue 6 years ago https://electronics.stackexchange.com/questions/334012/hsi-a... It sounds like the sampling clock frequency is not what is expected (but that's quite easy to check based on the transmitted signal so I'm quite confused) UARTs are nice if you are constrained on pins but SPI is always a safer bet where you don't have the necessary high accuracy clocks.

My guess is that the receiver clock glitches in some way when the MSI auto calibration runs, but it never showed up on the transmitter (and the device on the other side of the connection has never had a reception issue). I ended up disabling the auto cal feature during a UART reception and then turning it back on when the reception is done. SPI is definitely better as far as clocking, but MCU support as a SPI receive…

According to the documentation there is no calibration as such, the MSI clock simply runs in a phase locked loop (PLL) configuration with LSE (32.768 kHz). For example in 1MHz mode the MSI is setup to run at approximately 1Mhz, this clock then goes into a downscaler which downscales by a factor of 31 to approximately 32kHz and this is compared to the LSE clock to generate feedback for the MSI clock. When locked the MSI runs at 1015.8 kHz (32.768 * 31) so out by 1.58%.

It's also possible that the design hasn't been thoroughly tested and the PLL doesn't lock in certain conditions which could leave you with an unstable clock.

Re: Debugging hardware is hard

#27

Post by readmodifywrite »

barbegal wrote: post #26
readmodifywrite wrote: post #21

Earlier quoted context omitted.

My guess is that the receiver clock glitches in some way when the MSI auto calibration runs, but it never showed up on the transmitter (and the device on the other side of the connection has never had a reception issue). I ended up disabling the auto cal feature during a UART reception and then turning it back on when the reception is done. SPI is definitely better as far as clocking, but MCU support as a SPI receive…

According to the documentation there is no calibration as such, the MSI clock simply runs in a phase locked loop (PLL) configuration with LSE (32.768 kHz). For example in 1MHz mode the MSI is setup to run at approximately 1Mhz, this clock then goes into a downscaler which downscales by a factor of 31 to approximately 32kHz and this is compared to the LSE clock to generate feedback for the MSI clock. When locked the M…

The lack of status bits on the auto-cal is really unfortunate.

Turning it off during a UART transaction definitely "fixes" it.

I'm somewhat tempted to do the manual calibration the HSI instead.

Re: Debugging hardware is hard

#28

Post by barbegal »

readmodifywrite wrote: post #27
barbegal wrote: post #26

Earlier quoted context omitted.

According to the documentation there is no calibration as such, the MSI clock simply runs in a phase locked loop (PLL) configuration with LSE (32.768 kHz). For example in 1MHz mode the MSI is setup to run at approximately 1Mhz, this clock then goes into a downscaler which downscales by a factor of 31 to approximately 32kHz and this is compared to the LSE clock to generate feedback for the MSI clock. When locked the M…

The lack of status bits on the auto-cal is really unfortunate. Turning it off during a UART transaction definitely "fixes" it. I'm somewhat tempted to do the manual calibration the HSI instead.

Yeah a PLL without a status flag to indicate it is locked isn't good. I think there are also issues with stabilisation when using it with stop modes https://community.st.com/t5/stm32-mcus-products/msi-pll-mode...

If you really need the accuracy then regularly time the LSE clock using a timer clocked from MSI and apply the best trim values as described in this app note file:///home/tom/Downloads/an4736-how-to-calibrate-stm32l4-series-microcontrollers-internal-rc-oscillator-stmicroelectronics-1.pdf

Post reply on HN