When the MCU is powered on or off, the GPIO will output a pulse at that moment.

[Haixiang]

Greetings,

During the power-on and power-off processes of the STM32F407 chip, the GPIO used as the DAC output will be pulled high for 8ms. The goal is that the GPIO should remain low when there is no DAC output. Adding an external pull-down resistor has an effect but cannot completely eliminate it. It was not present during online debugging, only occurring when there was a power surge. After erasing the program, it still existed. Preliminary judgment is that it is a hardware issue. Is there any way to solve this problem?

Thank you so much for the help. @KDJEM.1 @LPetr.1 @TDK

 

 

 

 

 

[Haixiang]

1.Is there any difference between VDDIO and VDD? Will the power-on of VDDIO earlier than VDD cause this problem?

2.Does VCAP handle the situation that causes this problem?

[mƎALLEm]

Hello @Haixiang and welcome to the community,

What do you mean by VDDIO? VDDIO separated power supply is not present on STM32F407 . Only newer products such as STM32H5 and STM32N6 have this separated power supplies for the IOs.

You said: "It was not present during online debugging, only occurring when there was a power surge. "

What if you disconnect the DAC output from U26 pin 3? do you have the same behavior?

 

[Haixiang]

Thank you for your reply.

VDDIO is because I saw on AI that if it is powered on earlier than VDD, the GPIO state will be uncertain. If the power supply of STM32F407 does not have such distinction, then it is not caused by this reason. I tried to disconnect the PIN3 pin of U26, and the result was the same.

[TDK]

What chip exactly? What GPIO exactly?

Was an external pulldown resistor hooked up during the scope plots you took?

[Haixiang]

Thank you for your reply.

1.The chip is STM32F407VGT6. The GPIOs PA4 and PA5 are used as two DAC outputs. I have initialized them as regular IOs with pull-down mode.

2.No external pull-down was added during the process of taking the oscilloscope image. The external pull-down flyline test showed some effect but it couldn't completely eliminate the problem. Without adding the external pull-down abnormal pulse of 2V, there was still about 1V remaining.

[Haixiang]

Currently, I plan to add a switch behind AOUT and control it via IO. After the microcontroller has stabilized its operation, it is closed. When the power is off, it is disconnected to prevent abnormal output from the I/O ports. However, I know this is not the root cause of the problem.

However, there is also a risk that controlling the IOs might cause instability during power changes. So, I'm considering using the NRST signal as the switching signal. Is this feasible? NRST is the output of the reset chip.

[waclawek.jan]

How are all VDD/VSS/VDDA/VSSA/VBAT/VCAP pins connected?

JW

[Haixiang]

Thank you for your reply.

VDD is a voltage reduction from 24V to 5V, and V is reduced to 3.3V. All VDD and VSS are in a series connection. It seems that the VDDA and VSSA chips are not available. The VBAT is disconnected. The VCAP is grounded through a 2.2μF capacitor.

[Haixiang]

Do you think it might be interference caused by the power supply? The 3V3 ground and the 24V ground are connected in series.

[waclawek.jan]

1. Does the problem happen when you use the reset pushbutton?

2. As an experiment, try disconnecting TL431 from VREF+ and connecting VREF+ temporarily to VDD

3. What if the root of problem is some sort of current injection through the opamp connected to the DAC output, during the opamp's powerup? Try disconnecting the DAC output from the opamp (or removing the opamp itself, whichever is easier) and observe the DAC output alone. Or, alternatively, try to keep the opamp powered up, while powering down and then back up the mcu alone (having some means to disconnect the +5V rail, perhaps).

JW

[Haixiang]

1.This phenomenon occurs when the power is turned on and off. The reset button was not pressed.

2.I will attempt to observe the effect of connecting VREF to VDD.

3.Even without the operational amplifier chip, the same problem persists. We have already tried that.

[waclawek.jan]

Well, my guess is, that during the power-up, the following requirement is violated for a short period, due to the VREF+ rising slower than VDDA:

Or, it may be a similar problem, if VREF+ > VDDA briefly during powerup/powerdown.

JW

 

[Haixiang]

Yes, it seems that VREF will exceed VDD. Because VREF is derived from 5V, and VDD is derived from 3V3. And 3V3 is obtained by reducing 5V.

 

[Haixiang]

Perhaps it is because of the two 100μ capacitors in 3V3D that it fails to synchronize with the VREF voltage obtained from 5V during the power-up/down process. When powered on, the rise of VDD is slower than that of VREF, and when powered off, the drop of VDD is also slower than that of VREF.

[TDK]

I duplicated this on power-on on the NUCLEO-F429ZI board on PA4 which has VREF+/VDDA tied. Could not see a pulse on power-off. Wonder what's different there.

[waclawek.jan]

@TDK,

Interesting.

Duplicated means that you see a pulse on PA4 at power-on? Were you able to measure its width and/or relationship with the VDDA rise, perhaps maybe also with VDD?

JW

 

[TDK]

@waclawek.jan Yes. Let me take another closer look later today. I'm surprised the fix was reported to work. It was something like a 1 V peak pulse with a ~50 ms decay time. That was with no external pulldown resistor.

[TDK]

@waclawek.jan 

Nevermind. I do see a pulse on PA4 at power-on, but it disappears when a 1 kOhm pulldown is added. The pulse on PA4 at startup is somewhat higher than on other pins. Your reasoning here is likely correct.

Floating PA4:

With 1kOhm pulldown:

[Haixiang]

At that time, I also tried a 1K pull-down, but it couldn't be completely eliminated. Could you describe the circuit you replicated? I didn't understand.

[TDK]

I used a Nucleo board which has VDDA/VREF+/VDD all tied, so not quite the same circuit. I thought the behavior was the same but it was not.

Yes, in your circuit it's almost certainly due to VREF+ and VDDA not tracking each other.

[waclawek.jan]

I could quite well imagine also that the exact effect is dependent on exact threshold voltages of transistors, individual to every mcu, due to process variation. It may also depend on things like RC constants of the voltage rails, where R is ohmic resistance (and to certain extent inductance) of internal tracks and C is the sum of all parasitics loading these tracks internally. Besides transistors between the various voltage rails, there are also various protection and parasitic diodes, too. These all can interact during power-up/down in various surprising ways...

@TDK, please check my estimates: assuming the PA4 track at the Nucleo together with the scope probe's parasitic is around 100pF, the 100us rise time indicates cca 1MOhm "source", and the 1ms fall time indicates the 10MOhm impedance of a 1:10 probe. Even if this "calculation" would be one order of magnitude off, it's certainly not some "fully open" transistor to power rails; and as you've demonstrated, it should be quite possible to suppress it, if it is detrimental to the application... once one is aware of the existence of this effect, that is... However, the DAC's are also high output impedance (and the buffer is not rail-to-rail), so one may be hesitant to load it, so there some other means to mitigate this effect may be necessary (e.g. an external circuit pulling the output down while NRST is active).

JW

 

[Haixiang]

I didn't understand which transistor you were referring to. Is it in the 5V -> VREF circuit? Is it inside the MCU?

If it is in the 5V -> VREF circuit, then its threshold should not affect the result, right? Because its threshold value has little relation to the power-up and power-down speeds of VREF and VDD（The conduction time of the transistor? It should be done soon.）. I think the main reason that causes these differences is the two 100μf capacitors connected by the VDD（Charging and discharging time）.

If it is an internal circuit of the MCU, then I'm not quite sure.

[waclawek.jan]

> I didn't understand which transistor you were referring to

Inside the MCU. And I was only speculating. Sorry for the confusion.

JW