4 ms·

Someone else had a similar issue 6 years ago https://electronics.stackexchange.com/questions/334012/hsi-and-msi-applications-of-two-internal-rc-osc-in-microcont

Someone else had a similar issue 6 years ago https://electronics.stackexchange.com/questions/334012/hsi-and-msi-applications-of-two-internal-rc-osc-in-microcontroller 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.

YZF 2y ago
It's been forever since I used UARTs but I remember them being fairly resilient creatures. They center on the start bit and so as long as the clocks are close enough so you can sample the rest of the bits you should be good. Often the problem is configuration and not clock accuracy, e.g. how many stop bits or parity.
Gibbon1 2y ago
I had something like that 30 years ago on a Motorolla 68332 processor. It could generate the high speed CPU clock using the 32khz clock as a reference. What I found was the layout guy ran a digital trace through the pins of the 32khz xtal. There was enough coupling that digital transitions on that line would cause the high speed clock to swing wildly. Which showed up as garbage on the UARTs. Joyous thing is most of the time that line was idle. I cut and rerouted the trace and the problem went away.
readmodifywrite 2y ago
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).
- barbegal 2y ago
  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.
  - readmodifywrite 2y ago
    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.
    - barbegal 2y ago
      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-is-crashing-with-use-of-stop-modes-at-cold/td-p/58896 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

YZF 2y ago

It's been forever since I used UARTs but I remember them being fairly resilient creatures. They center on the start bit and so as long as the clocks are close enough so you can sample the rest of the bits you should be good. Often the problem is configuration and not clock accuracy, e.g. how many stop bits or parity.

Gibbon1 2y ago

I had something like that 30 years ago on a Motorolla 68332 processor. It could generate the high speed CPU clock using the 32khz clock as a reference. What I found was the layout guy ran a digital trace through the pins of the 32khz xtal. There was enough coupling that digital transitions on that line would cause the high speed clock to swing wildly. Which showed up as garbage on the UARTs. Joyous thing is most of the time that line was idle. I cut and rerouted the trace and the problem went away.

readmodifywrite 2y ago

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).

barbegal 2y ago
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.
- readmodifywrite 2y ago
  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.
  - barbegal 2y ago
    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-is-crashing-with-use-of-stop-modes-at-cold/td-p/58896 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