STM32 Gotchas

[Unixon]

Found this few days ago, looks like something worth keeping. Other sections are also interesting.
http://www.efton.sk/STM32/gotcha/

[peter-h]

Yes, this excellent site is written by wek who drops in here occassionally. Very few people know more than he does about this stuff.

[jnk0le]

Missed one thing. Peripherals that were not mapped to GPIO are non functional and all regs read 0 (at least through debugger).

[peter-h]

Non functional when?

[Psi]

Another one is that CAN and USB can't be used together in STM32F042 but can be in STM32F072.
It's not very obvious when reading the datasheets.
(It's to do with a shared RAM area on STM32F042)

[SiliconWizard]

Missed one thing. Peripherals that were not mapped to GPIO are non functional and all regs read 0 (at least through debugger).

Never saw that.

[jnk0le]

ok, false positive. Must have been a breakpoint before RCC was initialized. But still remember that someone was talking that F103 spi can't be used for CRC without one GPIO mapped.

[AndyC_772]

Useful list, I've hit a few of these over the years.

My "favourite" ended up being:
On STM32F7, when QSPI and the Icache are both enabled, the core issues speculative fetches over QSPI on exit from interrupts, even when QSPI is not in memory mapped mode.

That was fun to track down.

I reported it on the ST forum and, IIRC, the ultimate resolution ended up being along the lines of "yeah, the cache is broken, don't use it"... !

[peter-h]

But still remember that someone was talking that F103 spi can't be used for CRC without one GPIO mapped.

Can you please explain what you mean, explicitly?

All (?) peripherals in 32F4 I am using are memory mapped.

Do you mean SPI does not work unless you beforehand configure at least one GPIO pin?

[jnk0le]

Do you mean SPI does not work unless you beforehand configure at least one GPIO pin?

as an alternate function for given peripheral.

[peter-h]

Do you mean e.g. SPI registers are not readable until you have assigned a GPIO pin for the SPI?

[jnk0le]

something like "SPI can't be abused for its CRC until one of MOSI/MISO/SCK was mapped to a gpio". That was long time ago though.

[rf-fil]

Another one: WKUP pins require external pull-up / pull-down resistors. The WKUP / GPIO multiplexer is ahead of the GPIO peripheral, so none of the GPIO "settings", including internal pull-up/down resistors, apply when a pin is configured in WKUP mode.

(Also, only certain pins can be configured to wake-up mode, but that's not really a gotcha.)

[peter-h]

"SPI can't be abused for its CRC until one of MOSI/MISO/SCK was mapped to a gpio".

If this is a real bug then I don't expect many to have come across it because SPI with CRC is extremely rare.

[Geofrey]

Another one: WKUP pins require external pull-up / pull-down resistors. The WKUP / GPIO multiplexer is ahead of the GPIO peripheral, so none of the GPIO "settings", including internal pull-up/down resistors, apply when a pin is configured in WKUP mode.

(Also, only certain pins can be configured to wake-up mode, but that's not really a gotcha.)

From my own experience, not on C0s and G0s. Though the regular GPIO pull-up/down is indeed not working, there is a dedicated setting in the PWR registers. Probably the same for other series

[wek]

Thanks all for the kind words :-)

In the past few weeks, I heard mentions of the list from several unrelated sides. Maybe related to AI - I see frantic scraping in the logs. One of the mentions characterized the site as incredibly ugly - I understand that but I am also not going to change that.

And thanks for the additional gotchas. Some of them are already in the pipeline. The schedule is one gotcha per week; some of them are still waiting since the beginning as I tend to work on those I like at the moment...  Also, some are personal experiences and of course I prioritize those even if they don't have a wide appeal. There are one or two which were in fact written by others (credited of course), sent in by e-mail usually, I tend to push them forward, too.

Then there are some which are related to a wider range of problems (e.g. pins affected by bootloader, mainly in relationship with the "pristine chip goes to bootloader" property of some families; gotchas (and outright bugs) related to the insane complexity of speculative fetch/execution, caches, "security" features of the newer ARM cores, etc.) and I may need to do some research to avoid misinformation (yes there are many and I try to correct them as I learn about them). Time and energy is limited, though. I have work to do to pay the checks.

> something like "SPI can't be abused for its CRC until one of MOSI/MISO/SCK was mapped to a gpio"

This is probably consequence of "there's no Rx without clock being actually brought out to pin, even if master". Example of one which is in the pipeline since beginning. It's probably SPIv1-specific (i.e. 'F0/'L1/'F2/'F4), I haven't tried above and haven't seen anybody reporting.

> WKUP pins require external pull-up / pull-down resistors

I believe there are several different arrangements for this in the various STM32 families. Low-power-related issues are generally surprisingly complicated and I have little personal experience with them so I tend to avoid writing about them, although there appear to be a wealth of gotchas in that area, too.

JW

[Unixon]

Thanks all for the kind words :-)
In the past few weeks, I heard mentions of the list from several unrelated sides. Maybe related to AI - I see frantic scraping in the logs.

One of these scrapers was probably me backing up the entire thing
Your site it a treasure and it must be preserved. 

[tooki]

Thanks all for the kind words :-)

In the past few weeks, I heard mentions of the list from several unrelated sides. Maybe related to AI - I see frantic scraping in the logs. One of the mentions characterized the site as incredibly ugly - I understand that but I am also not going to change that.

But it’s highly functional and fast. I much prefer that to some modern, slow site that uses 90% of the screen for white space.

[az1]

Thanks all for the kind words :-)
In the past few weeks, I heard mentions of the list from several unrelated sides. Maybe related to AI - I see frantic scraping in the logs.

One of these scrapers was probably me backing up the entire thing
Your site it a treasure and it must be preserved. 

That's what the Internet Archive is for, and unlike AI slop scrapers it's well behaved.

[eTobey]

...
One of the mentions characterized the site as incredibly ugly...

The best thing about this ugliness:
Nothing is faster. And you can read it with a 25 year old browser! Or even older...

[wek]

Another one: WKUP pins require external pull-up / pull-down resistors. The WKUP / GPIO multiplexer is ahead of the GPIO peripheral, so none of the GPIO "settings", including internal pull-up/down resistors, apply when a pin is configured in WKUP mode.

(Also, only certain pins can be configured to wake-up mode, but that's not really a gotcha.)

In which STM32?

I just went through a bunch of RMs, and found that
- in older models ('Fxx, 'L0) enabling the WKUP pins in PWR_CSR.EWUPx results in forced in input pull down configuration
- in 'L4, 'Uxx, 'Gxx, 'C0, all pins' pullups and pulldowns can be set independently from GPIO by PWR_PUCRx/PWR_PDCRx (where x=A, B, C...), if PWR_CR3.APC is set; these settings are valid also for Standby and Shutdown, see Functionalities depending on the working mode table
- in 'H5 and 'H7, there is a register (called inexplicably differently, in 'H5 it's PWR_WUCR and in 'H7 PWR_WKUPEPR) which contain the WKUP enable, polarity and pullup-pulldown setting bits

I may have overlooked something, and also I haven't tried all of these, so maybe there is some model where WKUP pins do need externall pullups; please tell what was your setup.

JW

[rf-fil]

Another one: WKUP pins require external pull-up / pull-down resistors. The WKUP / GPIO multiplexer is ahead of the GPIO peripheral, so none of the GPIO "settings", including internal pull-up/down resistors, apply when a pin is configured in WKUP mode.

(Also, only certain pins can be configured to wake-up mode, but that's not really a gotcha.)

In which STM32?

I just went through a bunch of RMs, and found that
- in older models ('Fxx, 'L0) enabling the WKUP pins in PWR_CSR.EWUPx results in forced in input pull down configuration
- in 'L4, 'Uxx, 'Gxx, 'C0, all pins' pullups and pulldowns can be set independently from GPIO by PWR_PUCRx/PWR_PDCRx (where x=A, B, C...), if PWR_CR3.APC is set; these settings are valid also for Standby and Shutdown, see Functionalities depending on the working mode table
- in 'H5 and 'H7, there is a register (called inexplicably differently, in 'H5 it's PWR_WUCR and in 'H7 PWR_WKUPEPR) which contain the WKUP enable, polarity and pullup-pulldown setting bits

I may have overlooked something, and also I haven't tried all of these, so maybe there is some model where WKUP pins do need externall pullups; please tell what was your setup.

JW

You guys are right.. I guess the underlying gotcha is "RTFM".. which is about 5000 pages long...

[wek]

Thanks for the explanation.

I am painfully aware of the fact that it's 5000 pages, and quite often not even as a single document at a single website.

[Ground_Loop]

I didn't read through the whole list, but boot0 tied me up for a couple days on a recent STM project.

[SiliconWizard]

I never ran into this BOOT0 thing (requiring also BOOT1 to be pulled down too) as I haven't used the affected families, but I've run into another obvious BOOT0 issue not long ago on a STM32U5.

Not a gotcha, an obvious mistake in retrospect, but just something you should be careful with: I forgot to pull down the BOOT0 pin (mostly due to the fact this is a shared pin on the package I was using and BOOT0 didn't appear on the schematic symbol I used, so I just forgot about it). If left floating, it may boot to the internal bootloader randomly. In my case, it was doing it systematically. Since I didn't plan to use the internal bootloader at all, I just flashed options bytes to force booting to flash.

Just a silly mistake but be careful when using ready-made symbols, when special-function pins are not explicitely marked, they become easy to miss.