2024-02-06 08:21 AM
Setup:
I am developing an application where the Nucleo-144 board sits in a cabinet adjacent to a computer. The Nucleo-144 board is powered externally via a 12v power supply. I have selected this with the vin jumper and confirmed that JP2 is bridging pins 3-4. Finally, within the cabinet, the nucleo-144 board controls if the computer gets AC power via a relay. In addition to this relay, I need to be able to talk to the computer via serial to echo some messages and display power supply updates. There is a small daughter board we have designed that sits on top of the Nucleo-144 board that controls the relay as well as a power button (what we are triggering the relay with) and a pwm signal.
The problem:
The problem starts when I plug in a USB from the computer to the STLINK-V3E USB Micro-B connector (CN1) on the Nucleo-144 board. Nothing happens when the computer is off which makes sense. However, when the computer boots up and during enumeration (presumably?) the board resets. This causes the pc to lose power temporarily (due to the relay opening), causing it to turn off. This reset of the board is what I'm trying to prevent because it turns off the computer (due to the gpio going low for a moment).
What I Have Already Done:
This does not happen when the data pins of the USB are removed. Additionally, I have scoped VDD and have not seen any transients. As for what is causing the reset, I'm not sure. It seems both the external and software reset flags are set when it boots up again (found this out by using the USB for serial communication after the described condition occurs). It also has nothing to do with this computer directly, the board resets when any computer is connected to it. Lastly, I have scoped the nrst line and seen two low pulses with the JP3 connector disconnected. I'm not sure what is causing these though given that JP3 is disconnected.
My Guess:
My impression is that the STLINK-V3E has something to do with this, but the problem still occurs when I remove the nrst jumper (JP3), so I'm not sure how the STLINK-V3E could be causing this? And because this does not occur when the USB only supplies voltage, that seems to confirm to me that when the STLINK-V3E initially starts it is causing some reset condition that is affecting the microcontroller despite the jumper being removed.
Conclusion:
I could swap the USB I'm using to the other one (CN13), but I liked the idea of having access to the STLINK-V3E. However, if this is what I have to do to prevent my board from resetting I'm okay with that. If anyone had an idea on how to prevent this board reset on USB enumeration I would greatly appreciate the information. Also, if anyone had suggestions on additional debugging steps I could take, I would also appreciate those. If attaching the code could be helpful I'll do that as well. Thanks in advance!
2024-02-06 08:43 AM - edited 2024-02-06 08:48 AM
> My impression is that the STLINK-V3E has something to do with this
... is RIGHT !
I have a st-link V3 mods connected to a H743 board, just swd, swc, gnd connected;
and it just resets the H743 , when usb enumeration is running.
So its the firmware on the STLINK-V3 , that doing a software system reset.
(for me here - no problem, i just seen it...)
So can only :
>I could swap the USB I'm using to the other one (CN13), but I liked the idea of having access to the STLINK-V3E. However, if this is what I have to do to prevent my board from resetting I'm okay with that
or get other firmware for STLINK-V3 , without doing reset (maybe not all version of firm doing this).
or use other debug : j-link , cmsis-dap ...
2024-02-06 08:51 AM
Okay, I'm glad that others are seeing this as well.
Do you know of a way to modify this behavior? I'm aware of settings that affect the reset pin during debugging, but I do not think those effect what the STLINK-V3E device does during startup (I could be wrong though). Is there maybe a firmware version that doesn't have this behavior?
Any leads would be useful. Thanks!
2024-02-06 09:38 AM - edited 2024-02-06 09:40 AM
Ok, the V3 (with actual firmware ) doing this reset at its own startup -
but you could make a hardware, thats not switching off then !
Idea : put a simple D-flipflop there (or 2 : 74HC74 ) ;
you set the state of your power switch with the '74 outputs,
to switch it : just put D hi or lo , then pulse CLK . -> your hardware at state you want.
Now all pins/lines from H7 to low state again (with some 10k pulldown resistors).
+ a input pin/line : '74 output to H7 input , to check "see" the state of new '74 switch controller.
NOW any H7 cpu reset does nothing to the switch state...just in your software you have to check the "state" input, to see , where the switch is latched .
All you need is : the '74 flipflop, 2x 10k , and from cpu: 2 output (D , CLK), 1 input (to check state);
and output init to lo state ... :)
Good idea ?
2024-02-06 11:59 AM
That is fair, something like that could be a more robust solution to board resets (like if I ever want to do in situ reprogramming from the PC that would otherwise be turned off). I'll give it a thought.
In case anyone stumbles across this though, I ended up programming the other USB connector (CN13) for communication, so I didn't have to deal with the STLINK-V3E. However, if anyone wants to add a way to prevent this software reset that occurs on enumeration of the STLINK-V3E I would be very grateful.