The MCU doesn't program when it is COLD.

[CClar.3]

I have recently created a PCB in which I am attempting to program external FLASH via the QSPI interface. It is a very simple 2-layer PCB. The MCU is the STM32H723ZGT6. I am using an LDO to convert the 5V USB to 3.3V. There is a power LED. There are four discrete I/O LEDs that I am driving from the MCU. I am using two switches with internal pull-up resistors.

Programming is performed using an STLink V3Set on the TMS and TCK lines. I am using STM32CubeIDE as the development software. I have updated the drivers and firmware to the latest revisions.

My problem is that I designed and ordered some PCBs from JLCPCB. I assembled one and began my programming experience. I quickly became frustrated as the board would not program. In my attempt to remedy the problem, I began testing components and replacing anything that I thought might interfere with programming. Each time I would solder a new component on the PCB, the MCU would accept programming. If I let the board cool off, it would not accept programming. I discovered that the MCU will not program at room temperature but it will program if it is just above room temperature.

I populated a second PCB, thinking that I had an error with the first. The second one exhibited the same error. I replaced the MCU with a STM32H730ZET6 with the same results. I redesigned the PCB and ordered a new set. The new one exhibits the same problems.

I've had everyone in my office inspect it to see if they could find anything wrong. The pinouts are correct.

Some of the attempts I've tried:

1-Changing NRST capacitor values from DNP to 680pF to 0.1uF to 10uF (DNP does not work at all.

2-Removing the LDO and using 3.3V from an alternate source.

3-Using a capacitor in parallel to the boot0 resistor.

4-Cutting all traces from the programmer to the MCU and replacing them with wires.

5-Programming a known working PCB with the same MCU with the program and it works.

6-Programming the bad cold temperature PCB with a known working program and it doesn't work.

7-Changing programmers.

8-Changing the programming frequency.

Attached is a screenshot of the error. Has anyone else had this problem? Has anyone else been able to find a solution?

[FBL]

Hello @CClar.3​,

Here are some suggestions that might help:

1. Try to update the latest version of CubeIDE.
2. Check all solder joints to ensure they are all properly formed.

[S.Ma]

Make sure you have the boot pin, reset pin, polarized correctly (not floating), and SWDIO, SWDCLK and GROUND connected to the programmer. Slow down the SWD bus speed (using STLink) and check what happens.

[Tesla DeLorean]

Not familiar with your board design/implementation, so hard to critique the circuit.

Make sure you have VCAP capacitors, and you can see about 1.2V there.

Perhaps you have a grounding issue?

You should probably power cycle after programming, the H7 part doesn't respond to NRST the same way other parts. The system can latch on to the fact the FLASH was blank at initial power up.

[CClar.3]

Thank you for your responses.

1-I am using the latest version of CubeIDE. Drivers and firmware are all up-to-date.

2-I have checked the solder on this build multiple times. I have de-soldered and re-soldered the MCU. I have gone through four MCUs on three different PCBs, one of which is a different PCB build. All give me the same result.

3-The boot0 pin is connected to GND through a 10k resistor.

4-The NRST pin is connected to GND through a 0.1uF capacitor but I have tried various values ranging from 680pF to 10uF. I checked the result on an oscilloscope and it appears that the 680pF actually performs better than the recommended 0.1uF. But it doesn't matter which value I use, they all work when the board is warm and none work when the board is cold. The only thing that completely stops it from programming is when I leave off the capacitor.

5-I have switched to an STLink V2 and it seemed to have fixed the problem but as soon as the AC kicked on in the office, it stopped working. The difference between this board working and not working is 5 degrees Fahrenheit.

6-I am using two VCAP capacitors with values 4.7uF. The VCAP pins are connected to each other. If they need to be isolated, that would be a simple solution. But I have built multiple PCBs with this connection in place but this is the first time in which it did not work.

7-Power cycling after programming will not work as it fails to program initially. I can see how that might affect the FLASH latching and it makes sense. But sadly, I have tried this step to no avail.

8-Lastly, if I press my finger against the MCU, it will program most of the time. I don't believe this to be a problem with soldering or anything external to the MCU. I believe that it is internally a problem. I will attempt to replace it once more with a different batch MCU. I'll let you know how it goes.

[Tesla DeLorean]

What you're describing doesn't seem like a PC software issue.

Can you just provide a schematic, or section thereof, of what you've constructed?

VCAP typically 2x 2.2uF or 1x 4.7uF

Bad implementation here has been seen to cause issues with erasing and programming flash.

Use STM32 Cube Programmer as an independent application

ST-LINK/V2 (real ones), need VCC (3V3) to Pin 1, SWDIO, SWCLK and GROUND.

The software should be able to see/report the Target's voltage.

Make sure all the grounds are properly bonded.

Avoid conductive surfaces and foam if the board is on a bench.

[hkol.1]

I also encountered such a problem

[AScha.3]

just some idea to try, if you want:

• on boot0 a cap 10n or so, to gnd.
• if LSE clock active, set lse drive to high
• solder 470 ohm par. to a vcap cap (to 100% discharge core supply)

[CClar.3]

I would like to say that I have found the issue. The MCU seems to program every time now but I cannot completely validate it due to temperature constraints. In my schematics, I have a 10nF capacitor on the VREF+ line to ground. I misread the schematics and instead placed a 10uF capacitor. After replacing that capacitor with the correct one, the board seems to operate properly.

What I find interesting is that the VREF+ line is connected in parallel to the VDD line. I have thirteen capacitors on the VDD line that are all 0.1uF. So I don't know exactly if that one capacitor truly is the problem. All I know is that the MCU hasn't had an issue since I replaced that capacitor.

[CClar.3]

The capacitor change didn't work. It still errors out regularly.

But I may have an answer for this. My design is utilizing a fixed 3.3V LDO. Output voltage is roughly 3.325 to 3.35 volts. I have removed the regulator and supplied voltage from a bench top power supply. For some reason I set the voltage at 3.20 volts instead of 3.30 volts. But it programmed. It programmed every time. So I began stepping up the voltage in 10mV increments. It started getting problems between 3.22 and 3.25 volts. It was inconsistent in that range. But if I drop it to 3.20 volts, it consistently works. The programmer only works when it reads 3.22 volts or less. It never works when it read 3.23 volts or higher.

This is worrisome. On our production design, I am operating at 3.34 volts. I have never had this issue with that design or any other design for that matter. I'm guessing that I have a pin somewhere along the way that should be within a range but it's slightly too high.

I've included the schematics of the MCU. Maybe someone can point me in the right direction of incorrect pin connections.

[Aydin]

Hi @CClar.3 
We had ABSOLUTELY same problems and came up with your forum post! We ordered PCBs from JLCPCB and we use STM32F103 for the project. 

Your notes in here were complimentary to our trial errors. Our STM32 gets flashed when we heat up the board (or the chip alone) and not flash at all after we cool it down (we refrigerated to see the cold effect).

All of a sudden, we thought that the problem might be caused by residual flux or soldering grease. Then we have rinsed the boards with dishwasher detergent and dried completely. Guess what! It works since then with no problem at all. We will use cellulosic thinner for removing the residual flux or grease from now on. 

I hope this could help you or anyone else dealing with the same unknown and annoying problem. 

Cheers,