ST-link pulsing GPIOs when trying to re-connect after power cycle of target - Page 1
Forum section: electronics / general

author: uer166
author_rank: Super Contributor
timestamp: December 18, 2021, 12:09:22 am
content: Hi all, weird but 100% reproducible issue that I keep re-discovering with various STM32G4 MCUs in the following sequence:Run a debug session in STM32CubeIDEPull power from target, IDE loses connection but whateverRe-apply power to targetIDE seems to attempt to re-connect to targetDuring the re-connection attempts I see that during each attempt, the GPIOs pulse in a pulse train of 4 pulses!Bad things happen: gate drivers turn on in my MPPT, potentially blowing stuff up. In another project this corrupts registers of a MCP3914 ADC and it's no recoverable without power cycle.So uh, I guess what the hell. The pins don't simply go into high-z which would be acceptable since all default pull ups-/pull-down are safe obviously (edit: the screenshot shows them go hi-z but I remember that's not always the case). It would also be acceptable if MCU simply reset, but it doesn't, it seems that GPIOs do these pulses and the firmware keeps chugging along. This is a huge problem and a big dent in my FMEAs, has anyone else dealt with it, and is there any solution that can be done on the target only ideally.

author: thm_w
author_rank: Super Contributor
timestamp: December 21, 2021, 10:23:45 pm
content: So in your circuit there are reasonably low resistance pull-downs on these pins <50k?You should have current limiting when debugging to prevent any MPPT circuit from causing damage.ADC is also surprising, usually SPI will have a timeout to reset itself, is it not responding over SPI at all? Worst case you could wire up a IO pin to the Reset on ADC.For sure this does not happen if you disconnect the debug leads, and simply power off and on the device right?

author: DavidAlfa
author_rank: Super Contributor
timestamp: December 22, 2021, 01:07:13 am
content: If you're sure it's not caused by floating pins (as it's what it does when in reset state), remember that when the ST-Link connects, it might reset the stm32 several times.Between resets, the stm32 runs for a moment, and could be enough time for a lot of unexpected stuff happening.When I click over Program, I can see the OLED turning off (resets), but then it shows the boot screen for 1/2 second (Made a briefly run) before finally turning off and starting the programming.So maybe it's your own software doing that because it has enough time?Try adding a 1-2 second delay at the start of main and see if it makes any difference.

author: uer166
author_rank: Super Contributor
timestamp: December 22, 2021, 01:38:13 am
content: Quote from: thm_w on December 21, 2021, 10:23:45 pmYup, all pins have 10k default pull up/downs. My MPPT is current mode with external OC protection so it's not that big of an issue. Re: ADC: Microchip has silicon bug where it gets into a bad state and no amount of resetting it via the MCLR pin will bring it back to life. This is all beside the point and I'd rather just figure out wtf ST-link is doing.@David: I am sure it's not floating pins, and I am also certain that the STM32 RESET pin isnotbeing toggled. That's what I mentioned before, the MCU is not reset and keeps chugging along, yet a bunch of the GPIOs change state when ST-link reconnects. I've hit this issue now across 2 different project where there is little codebase overlap, and the parts are different (STM32G474 vs STM32G473 with different package).I'll try to come up with minimal code (well I assume even an empty main() loop with some GPIOs set to high and low would reproduce this), so make sure it's not the MCU being repeatedly reset, but so far it doesn't seem like the case.

author: DavidAlfa
author_rank: Super Contributor
timestamp: December 22, 2021, 02:24:17 am
content: What about posting which pins are doign that to trace the issue better?

author: thm_w
author_rank: Super Contributor
timestamp: December 22, 2021, 10:26:28 pm
content: Quote from: uer166 on December 22, 2021, 01:38:13 amI don't see that in the errata, microchip is aware?https://ww1.microchip.com/downloads/en/DeviceDoc/80000651A.pdfQuoteSo the answer to this is no then:"For sure this does not happen if you disconnect the debug leads, and simply power off and on the device right?"Program your existing code, disconnect debugger, and power off and on the mcu. No need for minimal code, yet.

author: uer166
author_rank: Super Contributor
timestamp: December 22, 2021, 11:46:19 pm
content: Quote from: thm_w on December 22, 2021, 10:26:28 pmYeah, they are. Can't say more, but if you read the datasheet REALLY carefully there are things that would imply it, but not fully forthcoming about it. I'll need some time to further work on the debugger part but it seems that it's not a common problem.

author: bson
author_rank: Unknown
timestamp: December 26, 2021, 03:41:35 pm
content: Could it be the boot ROM checking all the various UARTs, USB, SPI and whatever it can talk on before enabling JTAG/SWD?

author: DavidAlfa
author_rank: Super Contributor
timestamp: December 26, 2021, 05:28:51 pm
content: No, the stm32 starts executing whatever it's at flash address 0 (0x8000000).The bootloader only works when setting BOOT pins in other modes.