stm32f0-pico-dump
stm32f0-pico-dump copied to clipboard
racerxdl
always return a swdStatusFailure on swdInit
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.
- adjust DELAY_JITTER_MS_MIN with different value. (0u, 5u,10u, 20u, 50u)
- without any connection to target ic.
anything else i can check ?
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
Yeah same with me. Is this error indicating, that protection level 2 is in place instead of level 1?
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.
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.
Take a LA like "PulseView" and compare with ST-LINK V2. The JTAG->SWD command after line reset is missing here.
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.
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...
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 !
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?
I certainly added my stuff as Pull Request: https://github.com/racerxdl/stm32f0-pico-dump/pull/6
@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.
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.