Are pok3rtool and qmk_pok3r safe to use?

[zanzellor]

I'm looking into using qmk on my Pok3r, and just wanted to know if it's safe to flash qmk_pok3r using pok3rtool? Or are there still any gotchas that I should be aware of?

(I don't know where to post this, so I hope here is ok. Do let me know if I should post this elsewhere.)

[ChaoticEnigma]

I have been using qmk_pok3r on my Pok3r for some months now. I think the Pok3r is the only one that is stable right now, the Pok3r RGB and Core work but have some instability. Note that this firmware does not support the backlight LEDs yet.

The only real gotcha is that I have not yet tested updating to this firmware on a stock Pok3r. All of my keyboards have been erased and re-flashed so that I can debug them, and the unmodified Pok3r will have a different configuration of flash security bits. In theory, there should be no difference, but I can't confirm this.

You can get the latest pre-release from the artifacts here: https://gitlab.com/pok3r-custom/qmk_pok3r/pipelines?scope=tags , or just build in on Linux or OSX.

If you want to try it, the command would be ./pok3rtool -t pok3r flash QMK vortex_pok3r_default.bin. If you have any trouble, let me know.

[zanzellor]

Ok, so I flashed the firmware using the above command. However the keyboard doesn't seem to be working now. I've tried replugging it and trying it on a different computer. It isn't being detected by ./pok3rtool list, either. Have I bricked it?
Here's the log:

./pok3rtool -t pok3r flash QMK vortex_pok3r_default.bin
WARNING: THIS TOOL IS RELATIVELY UNTESTED, AND HAS A VERY REAL RISK OF CORRUPTING YOUR KEYBOARD, MAKING IT UNUSABLE WITHOUT EXPENSIVE DEVELOPMENT TOOLS. PROCEED AT YOUR OWN RISK.  
Type "OK" to continue:
OK
Proceeding...
Opened Vortex POK3R
Update Firmware: vortex_pok3r_default.bin
Reset to Bootloader
Current Version: 1.1.6
Clear Version
Erase...
Write...
Check...
Clear Version
Writing Version: QMK
Reset to Firmware
true

[ChaoticEnigma]

Hmm, that's unfortunate. Alright, let's see what we can do. Please attach the log file produced by pok3rtool, there should be a logs directory where you ran pok3rtool. The largest log file will be for the flash command.

Did you use the 0.1.3 firmware from gitlab, or build the firmware? If you built it, please give me the output of git describe in your local repository.

If you used the 0.1.3 firmware, switch the last DIP switch on the bottom (the one marked 4) to the ON position, and plug and unplug the keyboard a few times. Try a pok3rtool list after that.

[zanzellor]

I used the one from gitlab. I flipped DIP switch 4 and tried plugging and replugging it a few times, wasn't detected by PC or pok3rtool.
Here's the flash log:

[00:00:00:002] 0 E [|:] WARNING: THIS TOOL IS RELATIVELY UNTESTED, AND HAS A VERY REAL RISK OF CORRUPTING YOUR KEYBOARD, MAKING IT UNUSABLE WITHOUT EXPENSIVE DEVELOPMENT TOOLS. PROCEED AT YOUR OWN RISK.
[00:00:00:002] 0 E [|:] Type "OK" to continue:
[00:00:02:510] 0 N Proceeding...
[00:00:03:521] 0 N Opened Vortex POK3R
[00:00:03:521] 0 N Update Firmware: vortex_pok3r_default.bin
[00:00:03:522] 0 N Reset to Bootloader
[00:00:08:594] 0 N Current Version: 1.1.6
[00:00:08:594] 0 N Clear Version
[00:00:08:629] 0 N Erase...
[00:00:10:630] 0 N Write...
[00:00:11:470] 0 N Check...
[00:00:12:090] 0 N Clear Version
[00:00:12:123] 0 N Writing Version: QMK
[00:00:12:126] 0 N Reset to Firmware
[00:00:12:127] 0 N true

I also happened to have used the 'info' command before flashing, here's the log, just in case it's useful:

[00:00:00:002] 0 E [|:] WARNING: THIS TOOL IS RELATIVELY UNTESTED, AND HAS A VERY REAL RISK OF CORRUPTING YOUR KEYBOARD, MAKING IT UNUSABLE WITHOUT EXPENSIVE DEVELOPMENT TOOLS. PROCEED AT YOUR OWN RISK.
[00:00:00:003] 0 E [|:] Type "OK" to continue:
[00:00:01:131] 0 N Proceeding...
[00:00:02:141] 0 N Opened Vortex POK3R
0000  55160011 002c0004 76007600 00280000 03000000 00000000 00000000 00000000 | U....,..v.v..(..................
0020  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 | ................................
[00:00:03:146] 0 N 11001655
[00:00:03:147] 0 N firmware address: 0x2c00
[00:00:03:147] 0 N page size?: 0x400
[00:00:03:147] 0 N 128
[00:00:03:148] 0 N 128
[00:00:03:148] 0 N version_address: 0x2800
[00:00:03:148] 0 N true

I don't know if this is relevant, but I have the ISO version of Pok3r. Could it be because of this?

[mbetik]

To add some data for ChaoticConundrum ... I also tried to flash pok3r (ANSI layout; no backlight) with QMK firmware a while ago (really wanted to have Space-FN layout on my poker).

I got similar result with Zanzellor -- bricked keyboard. I have yet to try DIP-switch-4 with on/off -- would report the outcome later on.

Logs:

$ ../pok3rtool/.build/pok3rtool --ok -t pok3r flash space-fn vortex_pok3r_space-fn.bin
hid recv error: -60
recv error
Opened Vortex POK3R
Update Firmware: vortex_pok3r_space-fn.bin
Reset to Bootloader
Current Version: 1.1.7
Clear Version
Erase...
Write...
Check...
Clear Version
Writing Version: space-fn
Reset to Firmware
hid send error: -1
send error
false

Note that:

• In my case, I got a write error at Reset to Firmware stage.
• This might complicates stuff; I compiled pok3rtool / QMK in FreeBSD. I compiled by QMK for Tada68 succesfully so I thought operating-system doesn't really matter (I might be wrong though).

I kind of resign to the fact that I might need to unlock the keyboard as described in https://github.com/pok3r-custom/pok3r_re_firmware/wiki/HT32-Unlocking.

Cheers.

[zanzellor]

Should I get a hardware debugger? ChaoticConundrum, is this one ok? Has J-Link OB. Might be needing it.

[ChaoticEnigma]

@zanzellor
Ah, there's supposed to be more in those log files. Did you build pok3rtool in release mode? What revision of pok3rtool are you using? (git describe)

Well, the info command says there's nothing particularly different about that keyboard before the flashing. I don't expect being an ISO board would make a difference, they have the same keymap on the Pok3r, but they are different on the Pok3r RGB.

Can you take a quick picture of the bottom of the PCB on your keyboard? And also type out what the markings are on the microcontroller? (the largest black chip with lots of pins, should start with HT32F1...) Just so I can confirm there's no difference in the hardware.

@mbetik
I'm sorry to hear that, I wish I'd heard sooner. I'm actually surprised both compiled without issue on FreeBSD. I tested pok3rtool a long time ago on FreeBSD, but I'm surprised it still works.

I added the DIP switch recovery feature pretty recently, so it won't be in your version of the firmware. It checks the dip switches after hardware init, before USB init. Apparently it needs to be earlier, because the firmware is failing pretty early.

It looks like you are right, for some reason the flash security does need to be unlocked for this version of the firmware to work. But, I'd rather change the firmware to work with flash security enabled.

[ChaoticEnigma]

I'd just like to thank both of you for giving this a shot. Sorry it's not quite there yet, but I'm working on it. If you'd like to get your keyboard working again without messing with a hardware debugger, you could mail your keyboard to me with a return shipping label, and I'll put the original firmware (or qmk_pok3r) on it and send it back. Otherwise, read on...

As for a hardware debugger, I use a JLink EDU. I don't know how well a clone will work SEGGER's tools, so I'd probably recommend a JLink EDU mini. If you get the addon cable and breakout board on that page, it would make soldering the connection to the keyboard easier.

I'll update the documentation for the unlocking process with my current process.

[zanzellor]

I just did cmake and then make, so I guess whatever the default type is.
Revision is 9300321.
The chip says: HT32F1655. B524K0546G9 (I think, it's really hard to see) on second line.
Here's the image. It's uncompressed, so you can zoom in on details (right click & View Image).

[zanzellor]

I think those are legit chips that SEGGER only gives to eval board manufacturers; here's the link. Chinese vendors don't care about the license, of course :P
Anyway, it's ~$5, so no harm in trying. If it doesn't work, I'll get the J-Link EDU.

[ChaoticEnigma]

Ok, your PCB is the same revision as mine. I just wanted to make sure they didn't replace the HT32F1655 with a 1656 or something. They only other thing I see is that you have LEDs installed, and I don't. I'll put those in mine tonight, maybe it'll break it.

I ordered a few of those aliexpress JLink OB boards, that'll take a few weeks but maybe they'll work fine. I'd be surprised if they were real JLink chips, but what matters is if SEGGER software thinks they're real JLink chips.

[ChaoticEnigma]

Installed the LEDs, works for me. I'll look at the security bit settings and comment here if I find anything.

[zanzellor]

Ok, so I've ordered that debugger from the link above. Assuming it works, I have a few questions.

1. In the PCB diagram linked above, on the CN2 header, which hole is pin 1 (3.3V)? The one on the top that has a golden square around it? Or the one on the bottom? Just want to be safe, don't want a fried board.
2. I've cloned and built OpenOCD from your repo. Can you guide me on how to configure and use it? I've got openocd.conf from here and set HT32F1655 as target in it. When I run it, I get:

Open On-Chip Debugger 0.10.0-rc1-dev-00005-ge3fa2ecb-dirty (2018-07-21-12:13)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
adapter speed: 12 kHz
trst_only separate trst_push_pull
Info : No device selected, using first device.
Error: No J-Link device found.

Considering I don't have the debugger yet, is the configuration so far good?
When I attach the debugger and board, do I just start openocd and input the erase and flash commands? Or are there any other things I should do first?
3) Flashing bootloader: do I flash the firmware_builtin.bin file from here?
4) If all goes well, then I just use pok3rtool to flash the normal or qmk_pok3r firmware, right?

[ChaoticEnigma]

On CN2, the pin with the square pad (the top one) is pin 1.

Typically OpenOCD is run in the same directory as an openocd.cfg file, which sets up the connection. Your output looks right (for no JLink connected). When you do have a JLink to connect to, OpenOCD will start a telnet server, which you use to give it commands. So in another shell, do telnet localhost 4444, then the commands are entered at the OpenOCD telnet prompt.

Yes, that is the firmware you will want for the Pok3r. Writing firmware on these chips with my OpenOCD port is very slow, which is why I started using the SEGGER tools, but they are a little harder to set up, and overkill for just erasing the flash.

Yes, you will want to do a pok3rtool list and make sure it shows POK3R (bootloader): CLEARED. Then you can write firmware with pok3rtool. You may have to plug/unplug the keyboard after writing the flash, it may not reset automatically (you could also reset it from OpenOCD).

[ChaoticEnigma]

So I got the JLink clone from the AliExpress link above. It seems that the firmware was extracted from a legit JLink, and reprogrammed into an STM32. https://github.com/GCY/JLINK-ARM-OB

It does seem to work, but JLinkExe complains about it being defective (i think it tries to update the firmware and fails). This seems to interrupt my scripts while writing flash, so you have have to type the command by hand to make it work.