Extremely high current draw in L031K6T7

[Alec1]

I'm running into an issue while designing a relatively simple custom board with an L031K6T7, where after programming it the current draw exceeds 200mA and eventually breaks to the current limit of the power supply at 800mA.

When I assemble the board the current draw is negligible, I have used STM32CubeMX to generate the project and use an ST-Link/V2 with a TagConnect-2030-IDC cable to program the MCU over SWD. Something is going wrong in the programming of the device and causes the current draw to be far greater than it should be. Everything I've programmed it with has been generated from CubeMX and programmed over CubeProgrammer, the power supply to the L0 is 3.34V but I've verified that it never goes above 3.4V during power-on, which is within the 3.6V limit of the L0.

Any advice or recommendations on where to look would be really appreciated, I've read a fair bit of documentation but I'm still new to this and still learning.

The following is a detailed description of everything I've done around this issue, if it helps:

The first board I tried to program with relatively simple code that just set the enable pins high on a couple Boost converters and initialised/calibrated the ADC, and the current consumption read from the PSU instantly shot to the 800mA limit I had set for the board, the L0 itself becoming so hot that it burned to the touch within seconds. Booting into flash was dead, however, tying the BOOT0 pin high allowed it to still communicate with CubeProgrammer and I could program blink into the system memory and it functioned seemingly fine despite the extreme current draw. Measuring the resistance across VDD and GND on the chip (after removing it from the board) showed a resistance of 50 Ohms, however I don't know how relevant this is.

The second board I assembled I was more careful with. I first programmed it with just blink on the LED with the ADC, all communication and DMA left unconfigured in CubeMX. This sucessfully programmed the device and the consumption was 0-10mA. With all the enable pins set high the consumption was 50mA but once I enabled and calibrated the ADC the current consumption jumped up to 260mA. Even while holding nReset low the power consumption was over 150mA. Despite this the L0 was still programmable so I worked on the firmware of the board and continued verifying it with this high current draw. After a couple weeks working on it like this the current draw remained the same until, seemingly randomly when programming it with a new revision of the firmware the current draw spiked to 800mA and became extremely hot. Again the resistance across VDD and GND had dropped from the hundreds of kOhms to only 5Ohms but this time it was still programmable into Flash with BOOT0 low. Reverting the firmware to Blink had no effect in reducing the current draw.

Rather than assembling a completely new board I simply replaced the L0 on this second board with a new one. Before programming it the current consumption was <10mA but as soon as I connected to the MCU in STM32CubeProgrammer, the current draw from the power supply jumped to 550mA, before even programming it with a simple blink.

I've attached screenshots of my CubeMX setup incase I've made an obvious mistake that's causing these issues.

The TagConnect 2030 header connects the STlink to the board's VDD and GND, which shouldn't be a problem and the remaining pins are connected to the L0's nReset, SWCLK, SWDIO and RCC_CK_IN, I've attached a picture of the footprint.

[Mike_ST · Accepted solution]

Hello,

I don't think this is a software or STM32CubeProgrammer problem.

But probably a problem somewhere in the design. Show schematic if you like so people might have a look.

>> and use an ST-Link/V2 with a TagConnect-2030-IDC

I see there is a PA0/MCO(RCC_CK_IN) Pin on your TAG connect implementation... But ST-Link V2 doesn't supply MCO.

So what do you connect to that pad ?

[Alec1]

I'd connected that to the High speed clock input pin on the L0 thinking the ST-Link would be able to provide a master clock when using software debugging. I've been using VisualStudio Code for writing and compiling my code and have been able to use its debugging tool with the Nucleo boards, so assumed this was how to implement it but you're right this is wrong. I will try cutting the trace and seeing how things go.

[Alec1]

I cut that PA0/MCO trace after soldering a new L0 to the board and I created a new, blank CubeMX project that I programmed with blink and this successfully downloaded fine with <10mA consumption when the LED is on. I then slowly transferred different parts of the firmware over to this new file until most of the ADC, I2C and SPI stuff I'd done was on there and it behaved fine, staying below 50mA. I was then confident enough to try programming the main firmware file to the chip (not in automatic mode) and again, as soon as I touched the Tag-connect cable to the header on the board the current draw increased to 120mA (not as high as before) and now Cube Programmer can't find an STM32 target. The resistance across the SWDIO pin to GND is also now 64Ohms but the last bit of firmware I had working on it is still functioning correctly and isn't broken. Not sure what to try now.

[Mike_ST]

Hard to tell without schematics, but you're probably facing some HW design issue.

I see you have a pin called EN_neg3V3, so I guess you're switching some negative voltage...

Please check that you're not injecting negative voltage on any pins...

[Alec1]

I will find out whether I can send part of the schematics but I'm definitely not able to inject any negative current as there is no connection between any negative line and the L0. The firmware that is successfully running on the ( now unprogrammable) board functions correctly and there's no indication that there's anything wrong with the hardware apart from the programming side of things, and the ST-LinkV2 is now connected to the board with only SWDIO, SWCLK, 3V3, GND and nReset. I have access to an ST-Link V3, I could try replacing the L0 again and only programming it with the V3? But I doubt its the ST-Link that is causing the problem

[Alec1]

Here is the Schematic for the connections to the M0. I've marked that the PA0/MCO trace was cut on the board, and I've also marked that in cube-mx the PC14 & PC15 pins are disabled in cube MX because a 8MHz crystal was mistakenly used where the 32.7kHz LSE crystal should be. There shouldn't be anything else of relevance in the other parts of the schematic that could be messing with the M0.

[Mike_ST]

Hi again,

Can't see obvious problems.

I would check the voltages on PA8 and PA15, and whether they are within acceptable range (no 40V or -3.3v going back to the MCU).

And if you have different pages in the design, check all grounds are connected.

[Piranha]

Remove the R48! Again this thoughtless copy-paste from Chinese idiot made schematics... Why don't you follow the AN4467?

And also the PB0 is not actually connected to R44/R45.

[Alec1]

Thank you for your thoughtful answer, I have AN4467 here now and you're right they don't have an external pullup on the NRST pin, however can a 10k pull-up really be what is killing the MCUs each time? One of my colleagues has designs with 100k pull-ups on the NRST pins which work without issue.

I will be following AN4467 closely now, are there any other resources besides the Application notes that you would recommend to me?

Also, despite the schematic not showing the proper connection, PB0 is correctly connected to R44/R45.