burning with stlink V2

[losehu]

HELLO, EGZUMER
I want to use stlink V2 for burning
I modified the first two lines of gd32g030.cfg:
transport select hla_swd
adapter speed 100

Then use openocd to execute:
sudo openocd -c "bindto 0.0.0.0" -f interface/stlink.cfg -f dp32g030.cfg -c "write_image firmware.bin 0; shutdown;"

But prompt:
Open On Chip Debugger 0.11.0-rc2
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Force hard breakpoints
Info: The selected transport tool over low level target control The results may differ compared to plain JTAG/SWD
Info: clock speed 100 kHz
Info: STLINK V2J38S7 (API v2) VID: PID 0483:3748
Info: Target voltage: 3.273879
Warn: UNEXPECTED idcode: 0x0bb11477

Then OpenOCD terminated
I set CPUTAPID
Still useless, do you have any relevant suggestions?
I am sure my connection is correct and STLINK is working properly
AND I got the same results on both Windows and Debian

[egzumer]

Did you get it to work? I also have stlink, but I have never felt like messing with it. Could you send a photo with connected wires?

[losehu]

Did you get it to work? I also have stlink, but I have never felt like messing with it. Could you send a photo with connected wires?

I have solved the problem by modifying:
transport select hla_swd
swd newdap $_CHIP_NAME cpu -enable -expected-id $CPUTAPID
AND ADD:
set CPUTAPID 0x0bb11477

[Lar-Sen]

Here you have a ready to use config file for OpenOCD using STLinkv2 probe:
https://github.com/Lar-Sen/Quansheng_UV-K5_Kitchen/blob/main/unbrick-toolkit/OpenOCD/target/dp32g030.cfg

[losehu]

Hello, I am curious about how to read the bootloader of my own device, as I am using a Chinese version of the machine. I have noticed that its bootloader is different from yours, and I would like to try reading it

[Lar-Sen]

For China region, your dump should match https://github.com/amnemonic/Quansheng_UV-K5_Firmware/blob/main/firmware/raws/boot_v3.00.02.bin

I noticed only 1 little difference between bootloader versions (besides advertised version number), which resides in GPIO init functions:

MOVS    R0, #0x3C00
LDR     R1, =0x40060000		(target:GPIO.A)
STR     R0, [R1,#4]
MOVS    R0, #8
LDR     R1, =0x40061000
STR     R0, [R1,#4]
*MOVS    R0, #0x3C00    (in v2)    or     *MOVS R0, 0 (in v3 & v4)
*LDR     R1, =0x40060000 (only in v3 & v4)
STR     R0, [R1]

If your bootloader has anything different, I'll be pleased to get a dump of it :)

To dump bootloader alone, try this:
openocd -f interface/stlink.cfg -f target/dp32g030.cfg -c "reset halt" -c "dump_image myboot.bin 0 0x1000" -c "shutdown"

edit: you should power-cycle the device before dumping, otherwise as ROM would be masked, you'd get 0x1000 first bytes of the user region, not bootloader.

[losehu]

it works well,thank u very much!
very grateful for ur work!

[losehu]

Here you have a ready to use config file for OpenOCD using STLinkv2 probe: https://github.com/Lar-Sen/Quansheng_UV-K5_Kitchen/blob/main/unbrick-toolkit/OpenOCD/target/dp32g030.cfg

******** Launching 1 shot unbricking process with OpenOCD (STLink v2)...
.
Open On-Chip Debugger 0.12.0 (2023-10-02) [https://github.com/sysprogs/openocd]
Licensed under GNU GPL v2
libusb1 09e75e98b4d9ea7909e8837b7a3f00dda4589dc3
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select '.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : clock speed 960 kHz
Info : STLINK V2J38S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.241744
Info : [DP32G0xx.cpu] Cortex-M0 r0p0 processor detected
Info : [DP32G0xx.cpu] target has 4 breakpoints, 2 watchpoints
Info : starting gdb server for DP32G0xx.cpu on 3333
Info : Listening on port 3333 for gdb connections
[DP32G0xx.cpu] halted due to debug-request, current mode: Thread
xPSR: 0xc0000000 pc: 0x00000044 msp: 0x00000048

Checking ROM masking
[DP32G0xx.cpu] halted due to debug-request, current mode: Thread
xPSR: 0xc0000000 pc: 0x00000044 msp: 0x00000048
Erasing sector 0x07 = offset 0x0e00
Region cleared OK
Programmed up to 0x1000 (FLASH_ADDR=0xc400)
Checking ROM masking

ROM masking is set to 0b100. Setting ON...

Bootloader code programmed.
You can use uv_flash_fw to program main firmware, or just use stock tool to do it.

Checking ROM masking
[DP32G0xx.cpu] halted due to debug-request, current mode: Thread
xPSR: 0xc1000000 pc: 0x000000d4 msp: 0x200015d8
Erasing sector 0x77 = offset 0xee00
Region cleared OK
target/dp32g030.cfg:115: Error: could not read "k5_v2.01.27_fw": No such file or directory
in procedure 'uv_flash_fw'
in procedure 'write_image' called at file "target/dp32g030.cfg", line 315
at file "target/dp32g030.cfg", line 115

[losehu]

Here you have a ready to use config file for OpenOCD using STLinkv2 probe: https://github.com/Lar-Sen/Quansheng_UV-K5_Kitchen/blob/main/unbrick-toolkit/OpenOCD/target/dp32g030.cfg
I modified the cmd to：
@openocd -f interface/stlink.cfg -f target/dp32g030.cfg -c "reset halt" -c "uv_flash_bl bootloader.bin" -c "uv_flash_fw k5_v2.01.27_fw.bin" -c "shutdown"
After the burning was completed, my K5 turned into a brick

[losehu]

Here you have a ready to use config file for OpenOCD using STLinkv2 probe: https://github.com/Lar-Sen/Quansheng_UV-K5_Kitchen/blob/main/unbrick-toolkit/OpenOCD/target/dp32g030.cfg
I modified the cmd to：
@openocd -f interface/stlink.cfg -f target/dp32g030.cfg -c "reset halt" -c "uv_flash_bl bootloader.bin" -c "uv_flash_fw k5_v2.01.27_fw.bin" -c "shutdown"
After the burning was completed, my K5 turned into a brick

Fortunately, I returned to normal after using my own cfg

[losehu]

Glad to read "you are normal again", what about your radio ? ;-)

I am wondering if it is possible to debug code by configuring IDE and OPENOCD?

[egzumer]

This is the route that should work.

Setting up debugging:
https://www.yout-ube.com/watch?v=-p26X8lTAvo&t=1307s
Result:
https://www.yout-ube.com/watch?v=-p26X8lTAvo&t=1617s

I copied dp32g030.cfg and swj-dp.tcl from @Lar-Sen into target folder in the projects dir. The debugging progress tries to take of but fails to connect to with attempted 'gdb' connection rejected. That is where I'm currently at. (I knew this will be a pain in the ass, that is why I didn't want to touch it before :))

{
    "version": "0.2.0",
    "configurations": [
        {
            "cwd": "${workspaceRoot}",
            "executable": "./compiled-firmware/firmware",
            "name": "Debug with OpenOCD",
            "request": "launch",
            "type": "cortex-debug",
            "servertype": "openocd",
            "configFiles": [
                "interface/stlink.cfg",
                "target/dp32g030.cfg"
            ],
            "searchDir": [],
            "runToEntryPoint": "main",
            "showDevDebugOutput": "none"
        }
    ]
}

[Lar-Sen]

Sorry for the inconvenience. My "1-hand" unbricking script wasn't tested with my recent updates to the target cfg file.
I preferred using telnet to interact with openOCD in daemon mode (-d option, port 4444)
Anyway I've been using this config many times on different handsets: for sure it works :)
Glad you were able ro recover yours. And got normal again ;)
For debugging you should take a look at GDB which works in tandem with openOCD. OpenOCD itself is not a debugging tool.

[Lar-Sen]

My apologies again : The firmware file I provided in my repo was wrong! It was a full flash image, whereas 'uv_flash_fw' needs 0x1000+ region. Corrected.
This time it will work for good.

[Lar-Sen]

@egzumer , I never figured out how to set up IDE which GDB interface. May I suggest you to remove reference to 'interface/stlink.cfg' in your config file? It shouldn't lead to issue, but it is not necessary as there are implicit imports since we call swd protocol.

Also, for sure there's a way for the compiler to output an ELF formatted binary while it produces ROM file, as it seems to be expected here.

[egzumer]

I gave up. I couldn't make it to run with your config file at all. I'm using a small chinese stlink v2 dongle. I managed to make losehu method to kind of work. I was able to upload the flash file, but it was way slower than uart mode so I don't see the point. Debugging starts in the IDE, but radio doesn't react to that. I can't even do a reset through the interface.

I believe the firmware file (without extension) is the elf binary. It is definetely the elf format. This is what exif tool reports it as.

[Lar-Sen]

Regarding upload speed, I implemented must faster 'uv_fastflash_bl' and 'uv_fastflash_fw' procedures as you can see in the cfg, in a similar way as bootloader does when using uart flashing method.
Anyway I ran into flash controller/clock issues, so it doesn't work well every time. In fact it works well if bootloader is working and has loaded first...which is rather limiting.
I miss better timing values, and time to investigate for this.

Regarding classic word by word uploading method, it really works reliably using this cfg. There must be another issue with your setup if it's not the case.

I successfully hooked a GDB instance over openOCD. OpenOCD must run as a daemon and interface initialized (no 'shutdown' nor 'halt' here).
openocd.exe -d2 -f target/dp32g030.cfg

Then just launch gdb.exe, it will default attach to localhost:3333.

[egzumer]

I'm not good at this, but you seem to use jlink? I guess this is a different interface? I modified your file to use stlink. It didn't work from the start. Gdb attaches but fails to communicate to the device and disconnects. Although it causes the radio to halt.

[Lar-Sen]

Nope I use a cheap ST-linkv2 clone probe I suppose similar to yours:
https://voron.ua/files/pic/programmator/022026.jpg

JLink version of dp32g030.cfg has been done a long time ago. There was a working STLinkv2 version, but it needed optimizations and bug fixes.
You don't need to mod anything. Just redownload full 'unbrick-toolkit' package if using windows. Radio shouldn't halt if launching openOCD with -d2 -f target/dp32g030.cfg parameters.