Does STM system bootloader enable internal pull up on UART lines?

[Rostyslav S]

I am wondering whether STM system bootloader enables internal UART pull ups? I guess it doesn't, but I can't find this in ST docs.

My board does not have external pull ups on UART line and I want to avoid having RX pin floating.

[KnarfB]

STM Application note AN 2606 "STM32 microcontroller system memory boot mode" Figure 1. USART Connection shows pull-ups.

[Rostyslav S]

Figure 1 does only mention that external pull ups should be added. No mention about internal pull ups. That's why I am asking this on ST forum. I am looking for confirmation that there is not internal pull ups

[Uwe Bonnes]

Run the bootloader, connect with a debugger and read out the value of the GPIO PUPDR.

[Tesla DeLorean]

What STM32 part? Which pins?

Can you inspect the ROM loader code, or check the settings in debugger?

[waclawek.jan]

In the 'F4 bootloader, pullups on both Rx and Tx pins are switched on only after some activity on the respective Rx pin (I don't remember if it was any edge or is there some sort of short free-cycle debouncing too).

This was discussed here a couple of months ago, some user observed this as unwanted effect on some other family (I am lazy to look up the thread now) so this may be an universally used principle across all families.

ST is not keen to comment on issues like these, so I consider disassembling of the bootloader fair use.

JW

[Danish1]

Jan wrote: ST is not keen to comment on issues like these, so I consider disassembling of the bootloader fair use.

Although I don't object to anyone disassembling the bootloader they find in their current stm32, we can't rely on identical behaviour for a same-numbered part we buy some time in the future. All we can be reasonably confident is that it will comply with existing published specifications (and ST can get round even that by publishing an errata item!)

It might be that ST choose to make alterations to the bootloader code for a current part (for example if they discovered a weakness that defeated code-protection and a change to the bootloader could fix this).

Regards,

Danish

[waclawek.jan]

> can't rely

Generally I agree.

But in this particular case, it depends, how exactly would you use this information. E.g. if the question is "can I reliably replace an external pullup by internal being up" the answer implied by this information is "don't be silly, how are you planning to impose a reliable level transition before this algorithm enables the internal pullup?".

Other legitimate questions are "can I rely the internal pull-ups on unused interfaces are *not* on during bootloading" for which answer is generally "no" including the Tx pin where it may be a surprise (especially if that pin is used for other than Tx, e.g. as a trigger to launch an ICBM); and "I've measured this pin and there was no pullup so it's OK" for which answer is again "no" as the pullup may be switched on upon activity on this or other pin.

Btw. bootloaders are versioned and changed should result in PCN (yes I know the pitfalls of this "should").

JW

[Rostyslav S]

It's STM32L475 and I am wondering about UART pins, i.e. PA2, PA3, PC10, PC11.

Checking with debugger seems a good suggestion. Will get back once I have more details on this

[waclawek.jan]

Any finding on this?

Btw. this is the thread I was talking about above.

JW