Flashing POK3R with JLink clones

[ChaoticEnigma]

Moved issue from #23

@ChaoticConundrum

Since this seems to be the support thread, I'll be dropping some quick questions if you don't mind.

To start off I'll mention I have near zero soldering and electrical engineering experience so this is a rather "first project" if you will. So this might as well be horrible soldering that is causing the problem.

I've bought the J-Link clone as mentioned above which came in just fine and works as expected. I soldered some angled pins onto the Pok3r (original, VORTEX_DUAL_60_V1.1_20140331), compiled the openocd ht32f165x fork and ran it, googling quite a few issues a long the way.

I keep getting the following errors: Error: JTAG scan chain interrogation failed: all ones Error: Check JTAG interface, timings, target power, etc. Error: JTAG-DP STICKY ERROR Error: Invalid ACK (7) in DAP response

This might be of use: https://i.imgur.com/w21tde5.png

I've never used any of these tools or a debugger before, so if you can check whether the config looks ok that'd be real helpful. Or maybe post the openocd.cfg you used for the J-Link clone.

Now after searching it seems that it might be poor soldering. I've tried reseating and replacing the pins, but to no avail. Same issue with the DAP response. Soldering this stuff is rather hard when you cannot access the pins on the other side of the board due to the white plate (without de-soldering the keys that is as far as I can see).

I need to mention that the J-Link clone debugger is getting power from CN2 Pin 1 as long as the miniUSB is inserted into the Pok3r. Pulling out the debugger's USB from the computer keeps the debugger alive until connection to Pin 1 is removed or power to the Pok3r is stopped.

Power cycling the debugger and inserting it into the keyboard first without the USB to the computer will make it continuously reboot as far as I can see which is probably intended.

I've soldered Pin 1 (3.3v, red on the clone), Pin 2 (SWDIO aka green on the clone), Pin 3 SWCLK (yellow on the clone), and ground (black on the clone). I have not soldered reset due to it not being a part of the connector to the debugger.

The keyboard itself is still working fine as of now, as I haven't flashed anything or erased the flash yet.

Any tips or tricks? Or at least confirm my suspicions that the soldering job is simply botched?

Thank you!

[ChaoticEnigma]

@ChaoticConundrum

Sorry for pinging you again.

Seems like I actually got it working - At least partially.

Found the config file in the repo, worked perfectly. Using select swd instead of jtag was mostly the issue and I tried on a different Pok3r which worked immidiately.

The mass_erase command completes successfully, which is great!

The write_flash command however always fails, which you documented previously in this issue thread was a problem with the clone debugger failing to update the firmware which in turn disrupts "the scripts" which I can confirm it does via JLinkExe.

You also mention that you need to "type the command by hand" which is puzzling. I've tried looking through the OpenOCD commits, but I cannot find any commands related to flash write_image or what it does except C code related to mass_erase and such.

Could you give any insight in what command you are pointing to? Is it the following command? flash write_image ../disassemble/pok3r/builtin/firmware_builtin.bin 0

Or something completely different? Because the above is what is giving the error: error writing to flash at address 0x00000000 at offset 0x00000000

Any help would be much appreciated, as one of my keyboard is currently out of commission due to the mass erasure. Thank you!

[ChaoticEnigma]

@SondreHusevold

Hey, sorry I didn't get back to you on your first question, I ended up pretty busy this weekend. Glad to hear you got the first part sorted out. (Also in the future, it would probably be best to open a new issue. I tried moving it, we'll see how that works)

So, you're using my fork of openocd (i assume so, because mass erase worked), but that write command fails? Could you provide verbose logs for that command? I think debug_level 4 at the openocd telnet prompt will produce a lot more output. I don't think I actually tried OpenOCD with the clone JLinks, maybe it also has issues?

Alternatively, you could use the JLink tools, with a custom flash loader for the HT32. I mostly use this, since my hacked openocd patch is very slow when writing flash, and not very useful for general debugging (also not easily scriptable because of the telnet interface).

I'd recommend installing the above linked JLink flash loader (see readme) and using JLinkExe. It will work with the clone JLinks, you just have to wait ~10 seconds before doing anything, or it will be interrupted. After that 10 seconds, you'd type in JlinkExe loadbin ../disassemble/pok3r/builtin/firmware_builtin.bin 0x0.

Give one or both of those a try and let me know how it goes.

[SondreHusevold]

Thanks a lot for answering my request! Sorry, I'll make sure to make a new issue the next time.

So, you're using my fork of openocd

Absolutely. Compiled it from scratch, seems to work perfectly since the ht32f165x targets and commands all appear.

The debug_level 3 (seems to be between -3 and 3 according to the command) is quite verbose alright. Here's a more verbose log: https://pastebin.com/zDSJr1GD (contains a lot of garbage, the most relevant stuff is most likely at line 3749).

The "write memory" error is usually at completely random addresses, they are not consistent. However the "error writing to flash at address 0x00000000 at offset 0x00000000" is always identical.

I'll be attempting the JLink custom flash loader ASAP.

Again, thank you for all the help!

[ChaoticEnigma]

Looks like the first unusual line is 3728

Debug: 5120 23132 jlink.c:2090 jlink_swd_run_queue(): SWD ack not OK: 7 JUNK

It writes up to about 0x110, then there's an SWD error which stops the write. I don't think I've seen that before, it could be a bad connection, issue with the JLink clone firmware, excessive noise, etc. That third column is a timestamp in ms, so ~7 seconds since the start of that log. Maybe the issue is actually related to the issue with JlinkExe?

[SondreHusevold]

Giving the JLinkExe a go and no, seems like that failed as well.

Here's the main log: https://pastebin.com/m5r43aK4

Tried multiple times and mass_erasing through OpenOCD beforehand in some cases as well.

Sometimes it can also just fail with:

****** Error: Failed to prepare for programming. Failed to download RAMCode! Error while determining flash info (Bank @ 0x00000000) Failed to download RAMCode. Unspecified error -1

Seems to at least confirm there's something wrong somewhere, somehow.

Any ideas?

[ChaoticEnigma]

That paste says it succeeded writing flash, and just failed setting the PC after. To be sure, try verifybin ../disassemble/pok3r/builtin/firmware_builtin.bin 0x0. If that says its ok, try disconnecting the JLink, plug in the keyboard and try pok3rtool list.

[SondreHusevold]

Unfortunately doesn't seem to have worked.

J-Link>verifybin ../disassemble/pok3r/builtin/firmware_builtin.bin 0x0 Loading binary file ../disassemble/pok3r/builtin/firmware_builtin.bin Reading 9092 bytes data from target memory @ 0x00000000. Verify failed @ address 0x00000000. Expected D8 read FF ERROR: Verify failed.

Tried it in pok3rtool regardless, only my working Pok3r is currently seen (1.1.7). Even with the working on disconnected, it is not seen (not strange considering it failed).

I've tried a few times now, mass_erase -> flash in JLink, however fails to verify at the same address.

However some other news, I tried to set it to 4000hz instead of 12 inside JLink, which makes things go faster.

How it gets further into the programming:

https://pastebin.com/7fK2sBAY

[ChaoticEnigma]

That PC is at least in the right area. What does verifybin say now? Can you do a savebin <file> 0x0 0x20000 and post the <file>? A large read should tell us if it's a communication problem, and we can check if the flash is readable and correctly erased.

[SondreHusevold]

Verifybin fails as per usual. Same error.

I was really dumb and tried to warming the pins and attempting to wiggle the pins around and see if it helped in case there were some interference.

Needed to attempt multiple times, at least it answers again, however it doesn't seem as good as before as it'll fail at the "erasure" stage instead of the programming one.

keyboardFirm.zip

Here's the mass erased one. After attempting to flash the firmware and reading it afterwards it'll mostly respond with Reading 131072 bytes from addr 0x00000000 into file...Could not read memory.

However here's a saved bin from one attempt: keyboardFirm2.zip

Hashes reveal they're not identical at least.

Edit 2:

Might as well throw in a few logs from the "erasure failure": https://pastebin.com/d7fTnsTA (link was wrong previously)

Might as well mention that attempting to use 4000 kHz now fails every single time. 12 kHz does work until the failure in the log however.

[ChaoticEnigma]

They're both almost all FF, which is what they erase to, so that's good, but there are a few flipped bits in both, which is not good. That would be an unusual failure mode for the flash, so i am guessing they are communication errors. That could be the cause of most of your problems. Some things to try are shorter wires between the keyboard and JLink, check solder connections, and lower SWD speed (try 1000 Hz).

Short of those, and presuming the keyboard is OK, I would diagnose the issue to be the JLink clone. I don't remember if I mentioned it in the other thread, but SEGGER released a cheaper debugger, the JLink EDU Mini somewhat recently, presumably to compete with the clones. I would buy one of those (proabably cheaper shipping from Adafruit) rather than another JLink clone.

[SondreHusevold]

At least there's a chance of fixing it.

I'll be attempting more tomorrow, as it is getting extremely late. If I can't get anything working I'll buy the EDU and see whether that'll help. If that doesn't work either, at least it was a fun (albeit expensive) weekend project.

I'll make sure to holler if there is any progress. Again thanks a lot for the information!

[SondreHusevold]

Popping the champagne! We're in!

After trying multiple times to sort out the soldering I finally got it working at 4000 kHz and it verified perfectly.

Thank you for all help. Ẅriting from the keyboard right now and it works awesome with v117_patched.

Again, thank you for your help and your awesome software! Off I go flashing QMK stuff on this baby.

Edit: QMK flashed and working perfectly. Created a custom ISO layout for the 62 key nordic keyboard and it seems to work as expected.

This is some seriously nice software. Extremely well done! Very impressed.

[ChaoticEnigma]

Great! Good to hear. When using pok3rtool to flash, with two of the same keyboard connected, you will need to disconnect the keyboard you don't want to flash (it should warn you about this, been a while since I tried). This is because there isn't any useful way to differentiate them before you connect to them, and you don't want to erase the wrong keyboard.

Once you get qmk_pok3r installed, check out the GUI for it, Pok3rConf. Not everything works yet (firmware updates with the GUI don't), but the keymap editor works. It updates the keymap on the keyboard live, but doesn't save it persistently to the keyboard until you commit it (so unplugging the keyboard will reset to the previous keymap safely). I need more people to test this, I think I'm the only one that's ever used it.

Anyway, I'll close this issue. Let me know if you have any questions / suggestions. (don't be afraid to open issues). Cheers.

[a9udn9u]

@SondreHusevold

Sorry to ping you in this closed thread, I'm trying to flush my pok3r with a JLink clone too and had the exact same error while trying to erase the firmware using openocd. You mentioned that you fixed the problem by selecting the right config from this repo, how did you find the config? Below is the command I'm using:

openocd -c 'set HT32_SRAM_SIZE 0x8000' -c 'set HT32_FLASH_SIZE 0x20000' -f ./tcl/interface/jlink.cfg -f ./tcl/target/ht32f165x.cfg

My clone board showed as "Segger J-Link PLUS" in lsusb so I guess the interface config is correct, same with target config (Non-RGB Pok3r). I'm guess I need to specify the one for my particular board in tcl/board?

EDIT I managed to get further by adding transport select swd after loading the jlink.cfg file. The above openocd command gave me this screen:

Open On-Chip Debugger 0.10.0-rc1-dev-00005-ge3fa2ecb-dirty (2020-06-20-13:21)
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html
0x8000
0x20000
adapter speed: 4000 kHz
trst_only separate trst_push_pull
Info : No device selected, using first device.
Info : J-Link ARM-OB STM32 compiled Jun 30 2009 11:14:15
Info : Hardware version: 7.00
Info : VTarget = 3.300 V
Info : clock speed 4000 kHz
Info : SWD DPIDR 0x2ba01477
Info : ht32f165x.cpu: hardware has 6 breakpoints, 4 watchpoints

I didn't see the "Connected to target" message as stated in other posts. The first time when I run mass_erase, it failed with error "Target not halted", I manually run the halt command in telnet, then did mass erase, it seemed to work, I was also able to run write_image without error. But now the keyboard seems completely dead. It doesn't even show up in lsusb.

I can only connect it to the debugger, tried to redo mass erase and flush the v117, v117_patched firmware, nothing changed.

EDIT2 Trying JLinkExe, again, got a very similar error (https://pastebin.com/T1k1B8Uv) except mine looks even more broken it didn't finish flashing.

J-Link>loadbin ../disassemble/pok3r/builtin/firmware_builtin.bin 0x0
Downloading file [../disassemble/pok3r/builtin/firmware_builtin.bin]...
Comparing flash   [100%] Done.

****** Error: PC of target system has unexpected value after preparing target. (PC = 0x00000000)!
---------------------------------------------------------------------- Registers -------------------------------------------------------------------------------------
        PC   = 00000000
Current:    R0   = 00000000,    R1   = 00000000,    R2   = 00000000,    R3   = 00000000
        R4   = 00000000,    R5   = 00000000,    R6   = 00000000,    R7   = 00000000
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Failed to initialize RAMCode
Communication timed out: Requested 12 bytes, received 0 bytes !
Could not start CPU core. (ErrorCode: -1)Cannot read register 15 (R15) while CPU is runningCannot read register 7 (R7) while CPU is runningCannot read register 6 (R6) while CPU is runningCannot read register 5 (R5) while CPU is runningCannot read register 4 (R4) while CPU is runningCannot read register 3 (R3) while CPU is runningCanno
Unspecified error -1

EDIT3 I almost gave up, went back to openocd for the last try, I did mass_erase again then flash the builtin firmware, for some reason it magically worked... pok3rtool now shows it as CLEARED 🎆

[ChaoticEnigma]

@a9udn9u Seems like you got it sorted out, good to hear. Sometimes you really just have to do the same thing a couple of of times until it actually takes, especially with these clone JLinks, for some reason.