Black Pill - SWD programming issue possibly due to overvoltage on 3v3

[bp787]

First time working with an STM32 black pill.  I have a circuit that connects a Raspberry PI (3b) to the STM32.  I am getting errors when attempting to program it using openocd via the SWD lines.  I suspect it is a voltage issue, but I don't know how to verify.

The STM32 is supplied 5v from a mini buck converter.  I measured 5v on the STM32 pins.

On initial bootup, it comes up at 3.3v, and then rises to 4.2v.   This seems bad.   The rPI's 5v and 3.3v lines measure correctly.  There are no additional power sources other than the main 12v input on the PCB.

Upon booting of the pi, an initial openocd command is issued to query the device.  this partially works:

Open On-Chip Debugger 0.10.0+dev-01141-gc33d9efa (2024-12-11-17:24)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'swd'
none separate
Info : BCM2835 SPI SWD driver
Info : SWD only mode enabled
Info : clock speed 31200 kHz
Info : SWD DPIDR 0x2ba01477
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Error: stm32f4x.cpu -- clearing lockup after double fault
Polling target stm32f4x.cpu failed, trying to reexamine
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : Listening on port 3333 for gdb connections
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
** Programming Started **
Info : device id = 0x10006431
Warn : STM32 flash size failed, probe inaccurate - assuming 512k flash
Info : flash size = 512 kbytes
Error: stm32x device protected
Error: failed erasing sectors 0 to 0
** Programming Failed **
shutdown command invoked

After the initial communication, the output becomes limited:

 Open On-Chip Debugger 0.10.0+dev-01141-gc33d9efa (2024-12-11-17:24)
Licensed under GNU GPL v2
For bug reports, read
 http://openocd.org/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'swd'
none separate
Info : BCM2835 SPI SWD driver
Info : SWD only mode enabled
 Info : clock speed 31200 kHz
 Info : SWD DPIDR 0x76ee37ac
: in procedure 'program'
 ** OpenOCD init failed **

 
I also enabled debug level 3, and noted the follwoing:
arm_adi_v5.h:514 dap_dp_poll_register(): DAP: poll 4 timeout
Debug: 364 132 command.c:628 run_command(): Command 'dap init' failed with error code -5
User : 365 132 command.c:694 command_run_line():
Debug: 366 132 command.c:628 run_command(): Command 'init' failed with error code -4
User : 367 132 command.c:694 command_run_line():

and:
Debug: 283 28 bitbang.c:504 bitbang_swd_read_reg(): bitbang_swd_read_reg
Debug: 284 28 bitbang.c:426 bitbang_exchange(): bitbang_exchange
Debug: 285 28 bitbang.c:426 bitbang_exchange(): bitbang_exchange
Debug: 286 28 bitbang.c:526 bitbang_swd_read_reg(): JUNK DP read reg 4 = 00000000
Debug: 287 28 bitbang.c:554 bitbang_swd_read_reg(): No valid acknowledge: ack=0
Debug: 288 28 bitbang.c:615 bitbang_swd_run_queue(): bitbang_swd_run_queue
Debug: 289 28 bitbang.c:426 bitbang_exchange(): bitbang_exchange
Debug: 290 28 bitbang.c:622 bitbang_swd_run_queue(): SWD queue return value: 00
Debug: 291 39 bitbang.c:504 bitbang_swd_read_reg(): bitbang_swd_read_reg
Debug: 292 39 bitbang.c:426 bitbang_exchange(): bitbang_exchange
Debug: 293 39 bitbang.c:426 bitbang_exchange(): bitbang_exchange
Debug: 294 39 bitbang.c:526 bitbang_swd_read_reg(): JUNK DP read reg 4 = 00000000
Debug: 295 39 bitbang.c:554 bitbang_swd_read_reg(): No valid acknowledge: ack=0
Debug: 296 39 bitbang.c:615 bitbang_swd_run_queue(): bitbang_swd_run_queue
Debug: 297 39 bitbang.c:426 bitbang_exchange(): bitbang_exchange

I don't know much about the stm32, but I've been reading quite a bit about how to program, etc...  I assume that during assembly I did something wrong and damaged the STM32.  

I'd appreciate any suggestions/feedback on whether I just need to replace the current stm or not, as well as other debugging options.

[AScha.3]

Aha, ok, so I would call it a project with well defined target, to play around again ( with the ball ).  :)

And don't worry about the fakes everywhere - I buyed some black and many blue pills ( boards ) , never got a fake.

Just one was defective, because there was a small piece of solder shorting 5v to 3v3 at the onboard regulator. So I killed the chip when connect to USB.

The only one, that was not a STM32 chip, I could not complain and then get refund, because exactly reading, what the seller wrote, was: " better than STM chip, original from China" . 

So I got a GD32F103 , an arm chip produced by Giga Devices ( GD ) and almost compatible to the STM F103 ,  but this is not a fake, it's just a chip from another manufacturer. And the seller wrote it, so it was my fault, not to read every word he wrote.

Btw he was not lying, the ADC is really performing clearly better than the ADC on the STM F103 , less noise at small signals close to zero.

So if you buy a st-link V2, the cheap " clones" , or a black pill board again, just be not the first buyer, but look at seller with some 200 pcs sold and 4 or more out of 5 stars rating, and read buyer comments, when there's something like " working fine with STM IDE" , then this should be fine.

Or" not working..." , then don't buy this.

And look for " condition: new ", otherwise you will get anything from the trash fresh relabeled.

[bp787]

I disconnected the 3v3 jumper line from the STM32 SWD pins and now the MCU shows the proper voltage on the 3v3 pins.  From the schematics I can't tell why that pin was ever supposed to be connected to the PCB.  The STM provides the 3.3V there as an output to power the programmer, etc...  and it doesn't appear that the hole on the board has a trace going anywhere.

Was able to recover and flash the STM32.

I used the ST-Link v2 debugger with the STM Programmer software to access the STM32.  Once it connected, I had to go to the OB section and set the RDP (Read Out Protection) to a value of AA.  it was in a weird state with a value of 55, but that appears to fall into the level 1 protection.

I then had to change one of the write-protection check boxes (WRP) to off.  For whatever reason WRP0 was set to enabled (which is unchecked in the stm programmer software).

After that, successful firmware writing.

The Software on the PI is now reporting good MCU coms and returning the version number of the flashed firmware.


Appreciate all the help.  I'm now interested in learning some programing on these and have the tools (and a spare STM)