STM32F051 programming issue

[jogerh]

Posted on September 12, 2017 at 12:59

Dear Community,

I noticed a strange problem while attempting to program a STM32F051 device. The device is part of a larger circuit and gets its supply voltage from a 3.3V LDO regulator and the VDDA is supplied by a 3.3 V REF source. The problem is that I am not able to program the device using KEIL - it messages ''no target connected''� and using the STM-Link utility it is also not possible to log into the device (even if the reset pin is used for interconnecting under reset). The only way to program the device is by switching the boot0 to high.

What I've tested so far was to bridge the both ferrites inside the supply lines for VDD and VDDA - this at least sporadically allowed for programming the device.

Since earlier layouts using the same circuit never showed such behaviour I would be very happy if someone might give a hint what part of the circuit is close or beyond to the edge of what would work.

Version:1.0 StartHTML:000000284 EndHTML:000003154 StartFragment:000002640 EndFragment:000003122 StartSelection:000002643 EndSelection:000003122 SourceURL:

https://community.st.com/discussion/create.jspa?suppressMarkQuestion=true&question=true&containerType=14&containerID=2018

[Tesla DeLorean]

Posted on September 12, 2017 at 16:40

If this is an external ST-LINK pod make sure that VCC is connected to Pin 1 to power the drivers.

Check state of NRST

[jogerh]

Posted on September 20, 2017 at 11:57

Dear CLIVE,

thank you for responding – I used this design (copied from a source I’ve unfortunately forgotten) for 11 different circuits and it worked always without any doubts. The 3.3V where always generated on board so that I used only three pins for programming (CLK, SWDIO & GND - connected using needle contacts). Now for the current design  it stopped working – it might be that all other design are close before not working – but I've never noticed any strange behaviour.  What I’ve investigated so far is that both the ferrites L6 and L11 are contra-productive – replacing them by a solder bridge increases the chance that programming works. However for the first ever programming of a new µC this refused to work too (only setting BOOT0 to high allowed for programming). Decreasing the R40 (resistor connected to NRST) caused for other devices mentioned above (that showed no strange behavior before) various problems while programing. So this resistor might be important too. (Which I didn’t understand since accordingly to the datasheet there should be only a line-in driver).

Currently I suspect that the length of the track connecting BOOT0 with ground seems to be important. As shorter this track gets as more problems arise while programming.

[Tesla DeLorean]

Posted on September 21, 2017 at 01:14

Not sure a path length on BOOT0 is a big issue, it is a static signal.

If BOOT0 = High works well, try 'connect under reset' options, and review the state of NRST pin. A processor with 0xFF all over the FLASH is going to grind to a stop quickly, the process of gaining control via SWD taking more cycles.