Hello, We have a design whereby one of the STM32 RX inputs is driven hi by an external unit before the STM32 is powered up. This somehow prevents the STM32 from booting when power is applied to the STM32. Can someone shed any light on this please?

[JBarr.7]

Hello,

We have a design whereby one of the STM32 RX inputs is driven hi by an external unit before the STM32 is powered up. This somehow prevents the STM32 from booting when power is applied to the STM32.

We can manually reset the STM32 after that and everything works fine. We have several ways around this e.g. adding an external capacitor to delay the STM32 boot after power on but I'm trying to understand exactly what's happening so that we can choose the best solution.

Can someone shed any light on this please?

[AvaTar]

What pins exactly ?

Perhaps those floating inputs force the MCU in the system bootloader, or another system mode.

BTW, it seems the ability to introduce a problem description with a few words (a.k.a. "headline") seems lost nowadays.

[Tesla DeLorean]

The most common cause of this is the BOOT0 isn't pulled low and left to float, the part boots, but not into your code, as the part starts running at rather low voltages and VIL/VIH thresholds are lower too.

The part could also back-power via a pin driving higher than the supply.

Slapping capacitors on to reset circuits for synchronous parts is a road to support issues, if you need consistent reset, where the NRST is clamped low for >100ms and thresholds specific/multiple supplies, look at parts like the MCP120

[JBarr.7]

​Hello to all,

@AvaTar it was my first time posting on this forum so not sure of conventions. Apologies for not posting properly.

Back to the issue:

Good point on the BOOT0 pin but that's tied low so that's not the issue.

I'll try to describe the issue in a bit more detail:

We have one of our STM32 designs here (Unit A). It has a logic level serial port. 

We have another system Unit B that also has a logic level serial port. Unit A and Unit B can be powered up separately and this will be the case in the final implementation.

If we connect the serial port of Unit A to the serial port of Unit A and we power up unit B only. In this case Unit B has a hi level on it's TX pin which results in a hi level in the Unit A RX pin. In this case Unit A does not boot when it's powered up. If we manually reset unit A at this point then it boots normally.

We want to try to understand what's going on so that we can come up with the best solution. (We quickly tried a cap on the reset line just to try it out but that will probably not be our final implementation. )

We think that the power on the RX line is somehow partially powering up the STM core and upsetting the POR reset circuitry but we would like to get a better understanding of what's going on so that we can come up with the best solution.

Also is it possible that a voltage on the RX pin before Vcc is applied could damage the STM32? 

Thanks in advance for the help.

Regards.

[Tesla DeLorean]

>>Also is it possible that a voltage on the RX pin before Vcc is applied could damage the STM32?

I suppose if you get enough current flowing through the protection diodes.

They generally warn you about supply and pin levels (ie don't exceed VCC+0.3V, etc) so you don't create undesirable paths for current instead of over the more established ones engineered to distribute power across/around the device. Figure most of the cores can function at 1.2V

[David Littell]

Possibly a tri-state buffer at Unit A's RX which it enables only when it's ready to play with Unit B?

[AvaTar]

In addition to other hints: you can check if you end up in the system bootloader, by trying to connect to the BL, e.g. via the Flash Loader Demonstrator software. If that's the case, and said pin is not a BOOT pin, you will probably need to shield the MCU from those voltages.

> it was my first time posting on this forum so not sure of conventions. Apologies for not posting properly.

Not a special complaint about you, there are many (much worse) examples here on this forum.

From experience, I do not want to get involved in discussions with people that cannot collect their thoughts, and write unreadable sentences. They use to be endless.

To summarize, a short, proper headline and a detailed description of the problem increase your chances for a proper answer.