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.

[ChaoticEnigma]

I've been able to confirm that enabling flash security seems to cause qmk_pok3r to not boot correctly. I have absolutely no idea why, but I'll keep working on it (though flash security makes debugging 100% more difficult).

[mbetik]

@ChaoticConundrum Thank you for all the details. I managed to revive my pok3r back with QMK :).

In short, I bought that J-Link adapter from the above link, erased the memory and had it flashed with built-in firmware and then pok3rtool flash qmk-firmware.

If you are interested in log-files, just let me know.

[sveitser]

I'm also trying to unbrick my pok3er after flashing with a qmk version that I compiled myself.

I think I have a different debugger.

[10064.703861] usb 1-9: New USB device found, idVendor=0483, idProduct=3748, bcdDevice= 1.00
[10064.703863] usb 1-9: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[10064.703864] usb 1-9: Product: STM32 STLink
[10064.703865] usb 1-9: Manufacturer: STMicroelectronics
[10064.703866] usb 1-9: SerialNumber: PÿmH\xc2\x85USI&\xc2\x87

I had to play around with openocd configuration but in the end I managed to connect when I used.

interface hla
hla_layout stlink
hla_device_desc "ST-LINK/V2"
hla_vid_pid 0x0483 0x3748

# HT32F1655 Target
set HT32_FLASH_SIZE 0x20000
set HT32_SRAM_SIZE 0x8000

source [find target/ht32f165x.cfg]

My logs from flashing are:

> ht32f165x mass_erase 0                                                                                          
ht32f165x probe: 128 pages, 0x400 bytes, 0x20000 total
ht32f165x mass erase complete
> flash write_image ../disassemble/pok3r/builtin/firmware_builtin.bin 0  
ht32f165x probe: 128 pages, 0x400 bytes, 0x20000 total
wrote 9092 bytes from file ../disassemble/pok3r/builtin/firmware_builtin.bin in 6.822485s (1.301 KiB/s)

I first got an error about not being halted after which I just wrote "halt" into the prompt. Are my logs reasonable? Notably it does seem a bit "fast" compared to what's posted in the unlocking wiki https://github.com/pok3r-custom/pok3r_re_firmware/wiki/HT32-Unlocking and the sizes are different.

For now I still don't see anything showing in dmesg but I'll keep trying.

Edit: after plugging in the keyboard again with the debugger attached (was going to try flash the bootloader again) I noticed that it can't be halted anymore and now shows up in pok3rtool :fireworks: .

Edit2: Keyboard worked again after flashing the v117_patched firmware with pok3ertool. Now I also flashed vortex_pok3r_default.bin from gitlab CI artifacts and this works as well.

[ChaoticEnigma]

So... the keyboard is seen by pok3rtool? Can you pok3rtool flash the firmware? It looks to me like you've done everything right, I just haven't tried before with an STLink. That download is much faster than I see with a JLink, interesting.

[sveitser]

@ChaoticConundrum Thanks for the quick response. I made 2 edits of the previous post. It's all good now. I will continue with compiling a QMK firmware myself again tomorrow, hopefully.

[sveitser]

I now compiled the default keymap myself and flashed that with pok3rtool. This time it works. I'm 95% sure this is the same firmware that I bricked it with initially apart from some timestamp differences in the binary. Could this be due to the security bits that are mentioned above?

[ChaoticEnigma]

Yes, for some reason, ChibiOS does not seem to work on the HT32 with security bits enabled. It's definitely a design flaw with the HT32, because security modes should be transparent to the firmware. I've added a note to that effect in the qmk_pok3r readme. It's the main issue holding this project up, because the firmware is only usable to people with a debugger. Sorry that I didn't make that clear before.

[sveitser]

No problem! I ended up learning something. And thanks for the explanation.

[SondreHusevold]

@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!

[SondreHusevold]

@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 See #27

[markx]

Thanks for all the work folks! I read this and felt it's like a thriller story! 😁

So what's the conclusion? IIUC:

• It's not safe to flash the firmware on a locked device?
• It's safe to flash the firmware after the device is unlocked?
• There's a plan to implement this DIP switch recovery feature?
• There's an attempt to make flashing work with a locked device?

[ChaoticEnigma]

This applies to the Pok3r (non-RGB):

• It's not safe to flash a locked (flash security protection enabled) keyboard. (How they come from the factory)
• It seems to be safe to flash an unlocked device. (Requires a debugger to unlock)
• I did write code to erase the firmware if DIP switch 4 is on, but it may not have worked the last time someone else tried.
• When a keyboard is locked, it's very difficult to debug, because the firmware won't run when a debugger is attached. The problem is some undocumented behavior with the chips that ChibiOS is running afoul of. So the current course of action is to re-implement the firmware without the RTOS. Reducing the complexity of the firmware will either avoid the issue, or make it easier to diagnose.

Unfortunately I have almost no free time for the next two months, but I plan to be back at work on this after that.

In summary, this project is over budget, behind schedule, and has tripled in scope. So I'd guess you'd say it's doing fine? 😄

[markx]

Oh! So it needs a hardware debugger to use this custom firmware? 😞 That's a huge blocker. I would definitely try it if no extra hardware is required. 🤷‍♂️

How do the official firmware patches work then? How do they bypass the flash security protection?

Anyway, this is great work! Thanks for sharing!

BTW, what I really want is just to swap the Fn and Pn. I want move the Fn key to where Pn is, so I can press it with my palm. Do you know if there's a way to do this without extra hardware?

[ChaoticEnigma]

Yes, which is why the issue warrants basically starting over on the firmware from scratch. The issue is with the hardware, but only seems to be an issue with the port of qmk/ChibiOS.

I've had the request to move the Pn key before. If I get a chance I'll look into modifying the Vortex firmware slightly to do that.

[jackdoe]

Thanks for the great work! I managed to unlock-flash it using my raspberry pi 4 as SWD

interface bcm2835gpio

debug_level 2
adapter_khz 1

### those are the numbers for pi4
bcm2835gpio_peripheral_base 0xFE000000
bcm2835gpio_speed_coeffs 236181 60

## use pinout.xyz, those are pins 38 and 40
bcm2835gpio_swd_nums 20 21

## pin 12 on the PI
bcm2835gpio_srst_num 18

## dont forget pin 9 for Ground
transport select swd

and then using the openocd-ht32 fork(make sure you enable bcm2835gpio when compiling) and the firmware from pok3r_re_firmware ./disassemble/pok3r/builtin/firmware_builtin.bin

sudo openocd -c 'set HT32_SRAM_SIZE 0x8000' -c 'set HT32_FLASH_SIZE 0x20000' -f ./path/to/this-raspberrypi-native.cfg -f ./tcl/target/ht32f165x.cfg

then telnet localhost 4444
> halt
> ht32f165x mass_erase 0
ht32f165x probe: 128 pages, 0x400 bytes, 0x20000 total
ht32f165x mass erase complete
> flash write_image /home/jack/pok3r-wip/firmware_builtin.bin 0x0
ht32f165x probe: 128 pages, 0x400 bytes, 0x20000 total
wrote 9092 bytes from file /home/jack/pok3r-wip/firmware_builtin.bin in 62.253422s (0.143 KiB/s)
>         

I am posting it here because it took me a while to find the pi4 config for openocd and i almost gave up :) After that using qmk_pok3r and pok3rtool work like a charm!

the order is as described by @ChaoticEnigma

• pin 1 - the top red wire is 3.3v (unused)
• pin 2 - blue wire is SWDIO (goes to gpio 21 / pin 40)
• pin 3 - orange wire is SWCLK goes to gpio 20 / pin 38
• pin 4 - red wire is nrst goes to gpio 18 / pin 12
• pin 5 - black wire is GND goes to pin 9

---

Thanks again for your hard work! PS: I am writing this from qmk pok3r 😄

[manuel-arguelles]

@jackdoe Thanks for your post, I don't have a jtag adapter and was looking to buy one, but maybe I can avoid this since I do have couple of raspberry pi 3 and 4 around.

Could you please elaborate a bit more about the method? I have some questions:

1. Pin 1 (3.3v the square in CN2) you said it is unused? how do you power the board? shouldn't the pi supply the 3.3v to it?
2. pin 5 (CN2) doesn't go to any gpio?

Did you use anything else besides the pi? (in your picture there seems to be what it looks like and arduino mini?)

Thanks

[jackdoe]

@manuel-arguelles I am glad it was helpful

i used just a pi4, on the picture its just the pin extender i was using from the pi because it was easier to play with the wires

1. the keyboard was powered via usb, but i think you can also power it from the 3.3v to flash it, but i think that didnt work, but dont remember if i tried
2. pin5 on cn2 is ground i think

i found a picture that is more complete with the setup i was using, you can see the keyboard powered from the pi4 usb, and also pin1 (cn2) being in the air

keep in mind, it was quite an emotional journey haha

[manuel-arguelles]

@jackdoe thanks a lot! I'd try this soon, just to confirm, just one last question, did you use this configuration as it is: https://github.com/ChaoticEnigma/openocd-ht32/blob/master/tcl/interface/raspberrypi-native.cfg or something needs to be changed?

[jackdoe]

i did change it to be in swd mode instead of jtag mode, this is the config i used for pi4, for pi3 you have to change bcm2835gpio_speed_coeffs

interface bcm2835gpio

debug_level 2
adapter_khz 1

### those are the numbers for pi4
bcm2835gpio_peripheral_base 0xFE000000
bcm2835gpio_speed_coeffs 236181 60

## use pinout.xyz, those are pins 38 and 40
bcm2835gpio_swd_nums 20 21

## pin 12 on the PI
bcm2835gpio_srst_num 18

## dont forget pin 9 for Ground
transport select swd

[manuel-arguelles]

This is odd, I managed to compile it (after some changes in the code to avoid warnings/errors from recent gcc) but I'm getting:

Error: The specified debug interface was not found (bcm2835gpio) The following debug interfaces are available: 1: ftdi 2: usb_blaster 3: jlink 4: vsllink 5: ulink 6: hla 7: osbdm 8: opendous 9: aice

I built it with ./configure --enable-bcm2835gpio

[jackdoe]

@manuel-arguelles oh i remember i was struggling with this as well, i dont remember if i was using the tcl from the fork and the modern openocd-ht32, it was quite long ago and i didnt document the progress and now the image is lost so i cant check what i did

sorry i cant help :(

[manuel-arguelles]

Got it working, it was just the configure.ac not enabling the option for aarch64. Just before flashing, I tried with pok3rtool just to check, list command since to work, but not the rest, is that normal?

$ sudo ./pok3rtool list
List Devices...
Vortex POK3R: 1.1.5

$ sudo ./pok3rtool version
Unknown device!
No device found, check connection and permissions

$ sudo ./pok3rtool info
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...
Unknown device!
No device found, check connection and permissions

Is this normal or something that I should be worried about?

[jackdoe]

hmm i really dont remember as it was almost 1 covid year ago, i think i flashed it and then i tried the pok3rtool, you can see in picture above

On Sun, Feb 20, 2022, at 6:45 AM, Paco wrote:

Got it working, it was just the configure.ac not enabling the option for aarch64. Just before flashing, I tried with pok3rtool just to check, list command since to work, but not the rest, is that normal?

` $ sudo ./pok3rtool list List Devices... Vortex POK3R: 1.1.5

$ sudo ./pok3rtool version Unknown device! No device found, check connection and permissions

$ sudo ./pok3rtool info 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... Unknown device! No device found, check connection and permissions `

Is this normal or something that I should be worried about?

— Reply to this email directly, view it on GitHub https://github.com/pok3r-custom/pok3r_re_firmware/issues/23#issuecomment-1046167717, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIZMZFSHLND5WDXAQV2CEDU4B5Y5ANCNFSM4FJ7SSZQ. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you were mentioned.Message ID: @.***>

[manuel-arguelles]

It doesn't seem to work for me, not sure if maybe it's because i'm using the raspberry os 64 bit version overclocked.

I'm getting:

0x8000
0x20000
debug_level: 2
adapter speed: 1 kHz
BCM2835 GPIO nums: swclk = 20, swdio = 21
BCM2835 GPIO config: srst = 18
swd
adapter speed: 12 kHz
trst_only separate trst_push_pull
Info : BCM2835 GPIO JTAG/SWD bitbang driver
Info : SWD only mode enabled (specify tck, tms, tdi and tdo gpios to add JTAG mode)
Info : clock speed 12 kHz
in procedure 'init'
in procedure 'ocd_bouncer'

and it exits (without starting the telnet server), should I press some keys or anything like that to get it in a certain mode?

[manuel-arguelles]

Same result with raspberry os 32 bits. Should I try to flash it with pok3rtool, brick it and then try openocd?

All the connections seem to be ok, when I try it without power it does start the telnet client but fails with:

Error: Could not initialize the debug port

If I connect the board after and try to halt it I get Target not examined yet and no idea how to try to reconnect or initialize it

[jackdoe]

Same result with raspberry os 32 bits. Should I try to flash it with pok3rtool, brick it and then try openocd?

i didnt do that, i first flashed it with openocd

basically this was what i did:

sudo openocd -c 'set HT32_SRAM_SIZE 0x8000' -c 'set HT32_FLASH_SIZE 0x20000' -f ./path/to/this-raspberrypi-native.cfg -f ./tcl/target/ht32f165x.cfg

then telnet localhost 4444
> halt
> ht32f165x mass_erase 0
ht32f165x probe: 128 pages, 0x400 bytes, 0x20000 total
ht32f165x mass erase complete
> flash write_image /home/jack/pok3r-wip/firmware_builtin.bin 0x0
ht32f165x probe: 128 pages, 0x400 bytes, 0x20000 total
wrote 9092 bytes from file /home/jack/pok3r-wip/firmware_builtin.bin in 62.253422s (0.143 KiB/s)
>       

[manuel-arguelles]

Thanks @jackdoe and sorry for bothering you so much.

I think it's probably something wrong with my board, it's a second hand and quite old (some keys doesn't register consistently). I rebased the openocd-ht32 version with the current one and after some changes in the ht32f165x.cfg file:

# Cortex M3
set _TARGETNAME $_CHIPNAME.cpu
set _ENDIAN little
dap create $_CHIPNAME.dap -chain-position $_TARGETNAME
target create $_TARGETNAME cortex_m -endian $_ENDIAN -dap $_CHIPNAME.dap

I got different outpus depending of how much I move the pins (I did solder them SWD)

Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : BCM2835 GPIO JTAG/SWD bitbang driver
Info : clock speed 12 kHz
Info : SWD DPIDR 0xfe7e033f

Warn : Flash driver of ht32f165x.flash does not support free_driver_priv()

Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : BCM2835 GPIO JTAG/SWD bitbang driver
Info : clock speed 12 kHz
Error: Error connecting DP: cannot read IDR

Warn : Flash driver of ht32f165x.flash does not support free_driver_priv()

Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : BCM2835 GPIO JTAG/SWD bitbang driver
Info : clock speed 12 kHz
Error: Wrong parity detected
Error: Wrong parity detected
Info : SWD DPIDR 0xe7d00c77

Warn : Flash driver of ht32f165x.flash does not support free_driver_priv()

Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : BCM2835 GPIO JTAG/SWD bitbang driver
Info : clock speed 12 kHz
Error: Wrong parity detected
Error: Wrong parity detected
Error: Wrong parity detected
Error: Wrong parity detected
Error: Wrong parity detected
Info : SWD DPIDR 0xf9f80a77

Warn : Flash driver of ht32f165x.flash does not support free_driver_priv()

So I think that what I'm going to do is to desolder all the switches, give it a good clean, try to solder the cables to SWD properly and try again. Thanks again.

[jackdoe]

ohh looks like you are almost there, i had many frustrating hours to get it working :) i wish i documented the process better, but i was so excited when it worked that i jumped into qmk immediately

[manuel-arguelles]

@jackdoe thanks a lot! after re soldering the connections I was able to flash the firmware_builtin.bin, it took and excruciating 65 seconds and a half but it went through just fine...

However, now it doesn't show up in lsusb nor dmesg when plugged :/ I flashed the firmware_buitin.bin from pok3r_re_firmware/disassemble/pok3r/builtin/

is there something that I'm missing? pok3rtool doesn't seem to see it at all...

[manuel-arguelles]

I re-flashed it with

pok3r_re_firmware/disassemble/pok3r/builtin/firmware_builtin.bin
pok3r_re_firmware/disassemble/pok3r/v117/firmware_v117.bin
pok3r_re_firmware/disassemble/pok3r/v117/firmware_v117_patched.bin

and nothing, nothing on dmesg, pok3rtool list/version doesn't identify the device, nothing even in lsusb...

[manuel-arguelles]

Sorry for the noise, I restarted the pi, reflashed the firmware_builtin.bin and was able to flash the default keymap with pk3rtool! Thanks a lot!