Even if it doesn't help with the actual problem with the stm32 firmware extractor. But I got the blue-pill to work with the j-link.
I had to add "set _CPUTAPID 0" (instead of 0x1ba01477) in openocd/scripts/target/stm32f1x.cfg to suppress id error.
Another thing i read in openocd manual is, HLA-SWD mode (HLA = High-level adapters) which openocd supports for j-link and ST-link V2 adapter, does not work with the stm32f1-firmware-extractor tool. Because the tool uses the command maskisr that is not supported by HLA-SWD mode. And last but not least, the ST-Nucleo board has an integrated debug port on the upper side that uses HLA. I changed the wiring, only using the lower side of the ST-Nucleo board. Only 4 wires are needed like on the blue-pill.
Pinout for J-Link to ST-Nucleo board
J-Link ST-Nucleo CN7
1 Vdd 3,3V 16 Vdd 3,3V
4 GND 8 GND (or 19/20/22)
7 SWDIO 13 PA13 (SWDIO after reset)
9 SWCLK 15 PA14 (SWCLK after reset)
I was able to flash both devices with the J-Link and set the RDP option byte in openocd.
Now the readout for each device with or without RDP option byte matches but is different between blue-pill and ST-Nucleo and both are different to the original file. This is the actual main cause i'm stucked into. There has been no development in the stm32f1-firmware-extraction tool since the tool was released a few years ago.
https://www.eevblog.com/forum/microcontrollers/dumping-stm32-protected-firmware/... However the extraction has its issues, every few bytes cannot be read, the ones which match up certain IRQ vectors(7-13) ...
To set option byte in openocd i used this commands (consider that RDP level 1 is option 0 and RDP level 2 is option 1 in openocd, both can be set with lock or unlock):
openocd -f interface/jlink.cfg -c "transport select swd" -c "adapter speed 3500" -f target/stm32f1x.cfg
# in the other terminal
telnet localhost 4444
init
reset halt
# to read the actual setting
stm32f1x options_read 0
device id = 0x20036410
flash size = 128 KiB
option byte register = 0x3fffffc
write protection register = 0xffffffff
read protection: off
watchdog: software
stop mode: no reset generated upon entry
standby mode: no reset generated upon entry
user data = 0xffff
# to activate RDP1
stm32f1x lock 0
reset halt
init
reset halt
stm32f1x options_read 0
option byte register = 0x3fffffe
write protection register = 0xffffffff
read protection: on
watchdog: software
stop mode: no reset generated upon entry
standby mode: no reset generated upon entry
user data = 0xffff
# to deactivate RDP1
stm32f1x unlock 0
reset halt
exit
After unlocking RDP1, the flashmemory will be deleted.
To flash it again in openocd i used this commands (while openocd still running).
telnet localhost 4444
init
halt
flash write_image erase <full path to>/103_test.bin 0x8000000
verify <full path to>/103_test.bin
reset run
exit
The read command (while openocd still running):
time -p python3 ./main.py 0x00000000 --binary 32768 > ST-nucleo+RDP_read-test_new_PA13_PA14.bin
real 2719,66
user 18,80
sys 18,08
md5sum *.bin
f4ee82421a72b1210870185930cfc3f8 103_test.bin
8dbf03eeac65d567487ec8d0b63b4694 bluepill-noRDP_read-test_new3.bin
8dbf03eeac65d567487ec8d0b63b4694 bluepill+RDP_read-test_new.bin
668ce2d0bfb4a4abfd5a4fc92660020b ST-nucleo-noRDP_read-test_new_PA13_PA14.bin
668ce2d0bfb4a4abfd5a4fc92660020b ST-nucleo+RDP_read-test_newPA13_PA14.bin
I will end this stm32f1-firmware-extractor chapter here and figure out the jupyter notebook stuff for the chipwhisperer. Maybe a solution like in this example will do the trick
https://prog.world/read-secure-firmware-from-stm32f1xx-flash-using-chipwhisperer/