always return a swdStatusFailure on swdInit

[hpo14]

I am trying to make a dump from a new stm32f030c6t6 chip with pico under windows
and as the title, i got swdStatusFailure(0xE0u or 224 in deciaml) on the very first step (swdInit) of extractFlashData.
and im sure my wire connection are all good.

❯ python .\dump.py --port COM8 fw.bin
Reading from COM8 to file fw.bin
Received ready. Starting dump
Received Starting
Received Error reading: 224
Received DONE

Get the same error code with below test.

1. adjust DELAY_JITTER_MS_MIN with different value. (0u, 5u,10u, 20u, 50u)
2. without any connection to target ic.

anything else i can check ?

[alias095]

python .\dump.py --port COM6 fw.bin
Reading from COM6 to file fw.bin
Received ready. Starting dump
Received Starting
Received Error reading: 224
Received DONE

Also such a mistake

[redor303]

Yeah same with me. Is this error indicating, that protection level 2 is in place instead of level 1?

[racerxdl]

Check with a SWD debug cable if you can see the device . The Protection level 2 disables SWD , the protetion level 1 just forbids reading the flash memory.

[hpo14]

Check with a SWD debug cable if you can see the device . The Protection level 2 disables SWD , the protetion level 1 just forbids reading the flash memory.

The chip i used was a brand new ic without any protection, and it can be read/write by stink, through SWD interface, but failed with pico dumper.

[FMode]

Take a LA like "PulseView" and compare with ST-LINK V2.
The JTAG->SWD command after line reset is missing here.

[racerxdl]

Thats intentional. Thats not a generic dumper but one made specifically for dumping the firmware while protected. It skips several steps on SWD line to be able to do that. Thats the only purpose of this project.

[FMode]

This is the only difference I can spot. After LINERESET the JTAG->SWD command, another LINERESET, IDCODE and the target replies "OK". While it never replies when only the LINERESET is sent. Too bad that you can not switch off "JTAG->SWD" command in the ST-LINK utility.
https://research.kudelskisecurity.com/2019/05/16/swd-arms-alternative-to-jtag/
https://developer.arm.com/documentation/ddi0413/c/debug-access-port/swj-dp/swd-and-jtag-select-mechanism

edit:
no time today
Pullup data line and saw communication for the first time
static void swdDataIdle(void) { digitalWrite(SWDIO_Pin, HIGH); MWAIT; pinMode(SWDIO_Pin, **INPUT_PULLUP**); MWAIT; }
needs more investigation...

[FMode]

Finally works with my STM32F091xC soldered in device.
My device changes RESET line so it resets itself in regular intervals.
I added the JTAG2SWD sequence and I added the "connect at reset" function from ST-LINK utility.

Great stuff @racerxdl !

[Murakhovskyi]

Finally works with my STM32F091xC soldered in device. My device changes RESET line so it resets itself in regular intervals. I added the JTAG2SWD sequence and I added the "connect at reset" function from ST-LINK utility.

Great stuff @racerxdl !

How can I contact you?

[FMode]

I certainly added my stuff as Pull Request:
#6

[Murakhovskyi]

@racerxdl

Lucas, Good Afternoon.

In order to eliminate any factors that could interfere, I desoldered the chip (STM32F091) and soldered it directly to the LQFP64 legs:
64.VDD - 26 Pin PWR Pico
18.VSS - 28 Pin GND Pico
7.NRST - 27 Pin RESET Pico
46.PA13(SWDIO) - 14 Pin SWDIO Pico
49.PA14(SWCLK) - 15 Pin SWCLK Pico

But I have error 244 (E0), in your version.
I need this whole idea to resurrect the device whose M burned out.

Tell me what I'm doing wrong. I'll be very grateful.

[FMode]

Sorry after a lot of tries I can now communicate nearly stable via SWD.
I always get SWDFault as reply to the read request no matter what I try - also with a STM32F03 dev board just locked.
STM has never replied to this and I guess here is nothing to reply because that is just a hoax or only works under very few and random circumstances.
I was able to readout excactly 1 STM32F09 on a "real" PCB but it never worked again.

[shen-tian]

i tried this on a STM32F0 board with level 1 protection. it took a few dozen tries before i could even get a single successful read - mostly error 224 sometimes other codes. after a whole bunch of fiddling, i managed to dump the entire flash. a few breadcrumbs that might be useful for people who stumble onto this thread:

• what you use to turn the target on/off matters, in particular how fast it switches on/off after you toggled the pin. i used a scope to check this. a buck converter with an enable pin took too long to switch off. an LDO was much faster. this is affected by many things, including capacitance downstream of your switch, (e.g. on the target device). experiment, ideally with a scope; you might need to compensate for this in terms of how much time do you wait between power off and power on, and how long do you wait after power on before de-asserting reset (default 5ms);
• reading the original paper, the likelihood of successful read is affected by what the firmware code is actually running, so don't expect a strategy that worked well for one device to work well with yours. (this repo + writeup initially gave me the impression that it will just work. it's likely it just works with the device(s) it was tested with, but did not work much at all with my device). what worked for me is 1) a retry loop for each address, powering the device down for 1-2s between retries, and b) varying the jitter timing. this was vastly slower and took a few hours to dump 32k.

you can probably build an adaptive algorithm to get it closer to "it just works" for any firmware out in the wild, but i have my dump and am going to move on. hope someone finds this helpful!

thanks for the work @racerxdl !

[chithanh1991]

@shen-tian I need to repair a burnt circuit board, can you help me with the code you used successfully, thank you very much.