Electronics > Microcontrollers

Default pin states on unprogrammed STM32G030F6P6

(1/2) > >>

Hi Guys,

I don't have much MCU experience, so maybe someone here can provide some guidance/help/abuse.....

I have been building a short circuit tester from JDobry https://www.eevblog.com/forum/testgear/finding-short-on-motherboards-with-a-shorty-(with-display)/msg4304386/#msg4304386 using his PCB design and schematic (see below) + BOM (sourced from LCSC).
Official Pages:

I fitted supporting components for the MCU including the 3v3 switcher (U2) and the unprogrammed STM32G030 (U5), but noticed I have what I think is an excessive current draw (60mA). I removed the MCU and all unnecessary components, and current dropped to 50uA which is expected from my calculations from the schematic and components left fitted. I have 3 MCUs, so I re-soldered the 2nd one, and its the same 60mA current consumption.

I have a Chinese ST-LinkV2, and it can't detect the MCU. So I thought I should try and understand what the default states of the MCU pins might be on 3v3 power up in an unprogrammed state.

So, I thought I should first try and understand what the default states of the IO pins are on a powered but unprogrammed MCU, and then confirm that with a DMM. However, this is where I an confused.

The MCU https://www.st.com/resource/en/datasheet/stm32g030f6.pdf talks about default states upon reset (ie: PAx is set to analog inputs).
I then found AN2606 on the Boot Mode https://www.st.com/resource/en/application_note/an2606-stm32-microcontroller-system-memory-boot-mode-stmicroelectronics.pdf where on pp209 describes that in boot mode, certain peripherals are enabled (SPI, UART1, UART2) and maybe one of the enabled outputs on those peripherals corresponds to one of the PAx pins that are grounded in this design (as per the schematic, PA0, PA1, PA7, PA11[PA9] are grounded), and maybe the excess current are outputs trying to go high on a ground connection.

JDobry talks about programming the MCU with battery or via ST-Link, but on my Chinese clone the 3v3 supply drops to 2v at the 60mA current draw of this MCU, and I cant get it to connect. It does have the 20cm long wires, and I have seen references to cut these down to 5cm to make it reliable, so I will try that.

I am building up a second PCB, and I will solder my 3rd and last MCU onto this to cross-check. I need to order some 1.85v LDOs (U1) from Digikey as I sourced the wrong part from LCSC, so I am going to order more MCUs, and I'll choose one of the NUCLEO dev boards.

My only "left brain" thought last night is that I might have fried some IO pins electrically when soldering. It turns out my Microscope was powered via a UPS sourced 240v outlet, and my soldering iron was not, and was not grounded, and I measured 16v AC on my DMM between microscope base plate earth to soldering iron tip. This will be very low leakage, but I did find a reference to someone else who made the same mistake https://electronics.stackexchange.com/a/447300 although the outcome was catastrophic.

I have built many MCU projects before, I am confident of my soldering skills and everything has been electrically tested with two DMMs. I will unbox the DSO and check the 3v3 is stable and not overshooting or noisy.

Anyway, I thought someone might know what the default IO states of this MCU might be when unprogrammed but powered, and if I can confirm that I will have some confidence to load the last MCU on the 2nd board and keep trying. For some reason, this project just wont give up without a damn good fight. Funny how that happens every now and again.



--- Quote from: CaptainBucko on June 14, 2024, 04:59:11 am ---
I have a Chinese ST-LinkV2, and it can't detect the MCU.

--- End quote ---

How many of those do you have?
Have you tried swapping it with another one?

I have a bunch of those, and they tend to have "varying insides", with different brands and models of cloned / copied chips. I already have these for quite some years, and a few years ago the price of the ST-Link V3 from ST itself (Buy from Mouser, digikey, TME, etc) has become below EUR10 and If I had any problems with my chinese versions, I'd just buy a few real ones from ST themselves. Last time I tried to use one of the chinese dongles, it got "recognized" by STM32Cube and it updated it's firmware and still worked afterward.

I do like the form factor of these chinese things. If you want to look inside, you can just pull off the aluminum shell. But also beware, the signals on the 10 pin programming connector are not always the same between these things.

For the "default configuration", if you look in the reference manual, then you should see the "reset values" for all important registers.


--- Quote from: Doctorandus_P on June 14, 2024, 05:50:26 am ---How many of those do you have?
Have you tried swapping it with another one?

--- End quote ---
I have only one. It is detected correctly with the STM32CubeProgrammer and I upgraded its firmware to the latest version successfully. When I get the Rigol fired up tonight, I will probe SWCLK and SWDIO to see what is happening.  But given I am going to put an order in for Digikey, I will order a genuine ST-Link V3 from them, as this is not worth my time second guessing now.

Sounds more like some other problem than the Chinese ST-link not working.

The current drawn by the MCU is to high for a blank one, even if it would be in it's bootloader, which it only enters under certain conditions specified in the app note you linked to. See page 31, pattern 11 for the conditions.

Might be helpful for better insight if you post some close ups of the board with and without the MCU soldered.

AFAIK boot loader in STM32 use all possible boot sources in 'slave' mode. It will not try to send anything to anywhere, it just turn all appropriate pins to input mode and listen. It not set anything as output (however I could be wrong).
60mA definitely too much for blank CPU.

--- Quote --- I removed the MCU and all unnecessary components,
--- End quote ---
Try to remove only CPU - some of 'unnecessary' components can be in short cut (power blocking capacitor, for example)


[0] Message Index

[#] Next page

There was an error while thanking
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod