Embedded Rust Experiments: Is My STM32 MCU Running Fast?
nercury.github.io
Embedded Rust Experiments: Is My STM32 MCU Running Fast?
1–10 of 19 posts
Re: Embedded Rust Experiments: Is My STM32 MCU Running Fast?
#2It is always good to get to know your MCUs. When I first started using STM32s I would also scope the crystal and then toggle some pins as fast as possible to make sure.
Many gadgets later I trust the programmatic detection of external crystal use and appropriate PLL function. If you HAVE to know if the crystal fails you can use the CSS (Clock Security System) to generate interrupts in case you fall back to the internal oscillator.
Re: Embedded Rust Experiments: Is My STM32 MCU Running Fast?
#3Very nice writeup, those clock registers get so hairy and your notes are phenomenal!
Re: Embedded Rust Experiments: Is My STM32 MCU Running Fast?
#4That diagram of the clocking system is a good example of how the bigger MCUs are like having a whole computer on a single chip, with all the implications of complexity that brings. It's not enough to set up a single clock; you also need to make sure the clocks to the peripherals that are in use are also what you need them to be.
(I wish such diagrams in datasheets would let you click on the appropriate blocks to jump directly to their registers and description sections.)
Re: Embedded Rust Experiments: Is My STM32 MCU Running Fast?
#5That diagram of the clocking system is a good example of how the bigger MCUs are like having a whole computer on a single chip, with all the implications of complexity that brings. It's not enough to set up a single clock; you also need to make sure the clocks to the peripherals that are in use are also what you need them to be. (I wish such diagrams in datasheets would let you click on the appropriate blocks to jump…
Vendor tools for STM provide almost exactly what you wish for for the clock diagram.
Re: Embedded Rust Experiments: Is My STM32 MCU Running Fast?
#6It is always good to get to know your MCUs. When I first started using STM32s I would also scope the crystal and then toggle some pins as fast as possible to make sure. Many gadgets later I trust the programmatic detection of external crystal use and appropriate PLL function. If you HAVE to know if the crystal fails you can use the CSS (Clock Security System) to generate interrupts in case you fall back to the intern…
TIP: You should never scope a crystal directly as that could damage it. In production, for testing crystals, we output a PWM on a pin using the crystal as a source and measure that if the MCU doesn't have a built in functionality.
Re: Embedded Rust Experiments: Is My STM32 MCU Running Fast?
#7It is always good to get to know your MCUs. When I first started using STM32s I would also scope the crystal and then toggle some pins as fast as possible to make sure. Many gadgets later I trust the programmatic detection of external crystal use and appropriate PLL function. If you HAVE to know if the crystal fails you can use the CSS (Clock Security System) to generate interrupts in case you fall back to the intern…
TIP: You should never scope a crystal directly as that could damage it. In production, for testing crystals, we output a PWM on a pin using the crystal as a source and measure that if the MCU doesn't have a built in functionality.
STM32 has MCO outputs that can be used to more directly pass various (divided) clocks through.
Re: Embedded Rust Experiments: Is My STM32 MCU Running Fast?
#8That diagram of the clocking system is a good example of how the bigger MCUs are like having a whole computer on a single chip, with all the implications of complexity that brings. It's not enough to set up a single clock; you also need to make sure the clocks to the peripherals that are in use are also what you need them to be. (I wish such diagrams in datasheets would let you click on the appropriate blocks to jump…
Vendor tools for STM provide almost exactly what you wish for for the clock diagram. Example: http://www.emcu.it/STM32clk/STM32clk.html
I haven't used the STM Cube configurator for a while, but last time I did it was almost at FPGA software levels of user-unfriendlieness. If you changed the indentation on a magic comment in your code and then adjusted one of the clocks, CUBE would clobber your existing code and silently delete it.
Re: Embedded Rust Experiments: Is My STM32 MCU Running Fast?
#9Earlier quoted context omitted.
Vendor tools for STM provide almost exactly what you wish for for the clock diagram. Example: http://www.emcu.it/STM32clk/STM32clk.html
I haven't used the STM Cube configurator for a while, but last time I did it was almost at FPGA software levels of user-unfriendlieness. If you changed the indentation on a magic comment in your code and then adjusted one of the clocks, CUBE would clobber your existing code and silently delete it.
Yes, Cube autogenerates a lot of code and will overwrite things that don’t follow the inserted markers.
The original article even includes an example of using Cube to configure the clocks and then use those configurations together with Rust.
I agree that it isn’t ideal at all and kinda wonky. But more links in the datasheets would be nice.
Re: Embedded Rust Experiments: Is My STM32 MCU Running Fast?
#10It is always good to get to know your MCUs. When I first started using STM32s I would also scope the crystal and then toggle some pins as fast as possible to make sure. Many gadgets later I trust the programmatic detection of external crystal use and appropriate PLL function. If you HAVE to know if the crystal fails you can use the CSS (Clock Security System) to generate interrupts in case you fall back to the intern…
TIP: You should never scope a crystal directly as that could damage it. In production, for testing crystals, we output a PWM on a pin using the crystal as a source and measure that if the MCU doesn't have a built in functionality.
I've never heard of putting a scope probe on a crystal damaging it, though the load resistance (typically 1Megohm to ground) and capacitance (~5pF to ground) will affect the frequency.
This is why the PWM-out is useful -- it gives you a buffered, divided-down version of the crystal clock.