STM32L412 some GPIOs default to Output mode with blank flash

[dmanc.1900]

Hi,

This can be considered as a bug / something to be improved on the ROM bootloaders (at least in the L412 family):

Our specific design uses TIM16_CH1 in PWM mode to control a small flyback converter. As a safety measure, we've added a pull-down to this line, so nothing bad will happen before the application firmware takes control, configures the GPIO as output and ensures a safe duty-cycle for this signal...

The issue comes when the device is powered-on for the first time: As the Flash is blank, the ROM bootloader kicks-in, which is a handy feature, but then this GPIO is set as an output, with a High-level, therefore overriding the safety pull-down resistor. This causes our flyback converter to operate out of the safe range and therefore being destroyed.

We've nailed down the issue to the bootloader configuring the SPI1 in slave mode, that for our specific GPIO (PA6) is the MISO line. As the SPI1_NSS line was left floating in the design, it the slave is Selected (SPI1_NSS -> LOW), setting SPI1_MISO (PA6) in output-high-level.

This issue could have been avoided if:

1) the ROM bootloader enables the internal Pull-ups for the SPIx_NSS so the SPIx_MISo is left in high-impedance if the user don't force the SPIx_NSS to GND.

2) This issue is documented in the corresponding errata and/or hardware design guideline documents.

I hope that this issue will reach the relevant personal in ST so actions can be taken and avoid valuable days of debugging and PCB re-spinning to other customers.

Thanks in advance!

All the best,

Daniel Mancuso.

[Amel NASRI]

Hi @dmanc.1900​ ,

That is an interesting case requiring some investiguation.

A quick check in AN2606, it is precised that NSS must be connected to the ground:

This is said, your proposals remain valid & I'll share with our Bootloader Experts.

-Amel

[waclawek.jan]

The bootloader is not supposed to set *any* pin to output (including AF turned to output by the associated peripheral), until the protocol associated with that pin is initialized. In case of SPI, until NSS is pulled down AND master has sent Synchronization Byte (0x5A), as per AN4286.

If it does otherwise, I consider it to be an outright - and frankly, a very unsettling - bug.

Now what the bootloaders are already known to do (although, characteristically to ST, entirely undocumented) is, that they switch pullups/pulldowns upon activity directed towards given peripheral.

So, the question for @dmanc.1900​ is: what you observe on SPI1_MISO (PA6), is a "hard" output, or a pullup? (i.e. what's the impedance of any circuit connected to it, and if decreased e.g. by using a suitable external pulldown significantly lower than the nominally 40kOhm internal pullup, does the behaviour change?)

If it is a "hard output", do you have, with the pristine mcu, any activity on the SPI pins, which can be interpreted by the target as 0x5A?

Btw. you can check bootloader's behaviour on the pins yourself, using a debugger, just put the mcu into bootloader mode, stop in debugger and read out and check the relevant SPI and GPIO registers' content.

Now, my doubts as per ST's crew competence (and, @Amel NASRI​ , please do quote me):

• AN4286 rev.11 in Fig.3 indicates, that there are valid data (0xA5) on MISO when receiving SYNC
• throughout whole AN2606 rev.52 , the SPI MOSI and SCK are described as "Slave data Input line, used in push-pull, pull-down mode". What exactly is a push-pull input?

JW