Porting firmware to proprietary keyboards about controller HOT 13 OPEN

I was just wondering about a similar thing

I really like the FC660M layout, yet the non-programmability is a show stopper, it would have been great if there was a way to upload a new firmware

I've seen similar discussions before, yet I haven't seen anyone reflashing a stock keyboard yet - if it was possible, I'm guessing there wouldn't be the need for additional controller devices - yet there is - so I assume such a thing isn't practically possible

from controller.

@kaansoral I am not familiar with that keyboard.

However, I would see at least "some" hope for usb keyboards that already provide usb nkro support, since that means most likely they need a beefier arm chip to do it.

from controller.

Actually, when you think about it, Poker 3, KBP V60, these are all firmware upgradeable keyboards, so like you mentioned, it's theoretically possible for these keyboards to switch to a custom firmware

from controller.

Yep, porting this firmware to other keyboard should be totally doable. Not for the faint hearted, but I've already ported across two different architectures (AVR and ARM) so a lot of the heavy lifting is already done.

If the chip has at least 16 kB of RAM and 64 kB of Flash it should be totally doable without any issues whatsoever (the Holtek chip has 32 kB of RAM and 128 kB of Flash, so you're golden).

Using different bootloaders isn't a problem tbh. I just have my own semi custom McHCK one because I needed one. For the Teensy stuff, I rely on the pjrc bootloaders.

If you're really serious about doing this, I'd recommend getting a Teensy 3.0/3.1. Maybe even a devkit for the HT32F1655 as well.
Once you can compile and load the code on another device (access cli, etc.). Then you should be ready to start porting it. I can write up some documentation on what pieces of code will need to be ported (kll won't :D but lots of stuff like the key scanning and USB device driver will likely need some work).

The more info you can give me about available pins and flashing methods means I can suggest additional features/debug possibilities. For example, if UART pins are available you can debug USB initialization instead of having to write a bit-banged UART driver.

from controller.

Thanks @haata!!! It is encouraging to learn you think this is not a crazy idea.

I could absolutely get a teensy 3.0/3.1 to aid in this endeavor. Would you mind elaborating a bit on why you think one would be useful? At first I thought that perhaps the teensy shared the same processor as the pok3r keyboard, but from what I can tell it is also based on the kinetis freescale processor of the infinity keyboard, so I am not entirely sure how it fits in.

Perhaps I should mention that I already have three or so custom mchck's lying around. They are ALMOST vanilla mchck's with the exception that I used the K22DX processor line instead (back then I had to add support to the programmer for this family, but my patch has since been merged into the mchck trunk, so I my boards are now supported by the official mchck toolchain).

A dev board for the HT32F1655 would most definitely be useful. Unfortunately the only thing I can find is an ESK32-310 with an e-link32, and they seem to be unavailable in ebay. I agree that carrying out this project without such a devkit is difficult (if not impossible), especially since I don't want to brick my keyboard in the process :(

I could use one of the mchck's as an swd bridge to the HT32F1655. I have only really scratched at what swd can do. Most of my embedded experience is with AVR/PIC development, and my only experiments with ARM thus far was building my own mchk's and submitting patches to get it to work wit the K22DX famliy I was using. Hence, I will appreciate a lot any suggestions you have here.

All that being said, there are still things which I can figure out without the devkit or even swd.

Namely my plan of attack was:

• figure out the pin mappings from the HT32F1655 to the keyboard matrix, plus the pins used for usb (and swd, in the case they are broken out).
• reverse engineer the firmware uploader that vortex already provides (ideally, we can use that, so everyone with a vortex poker 3 keyboard can use your wonderful firmware without having to physically hack their keyboard).
• learn exactly what files from the kiibohd/controller codebase I will most likely have to port to the new architecture.

from controller.

So, you'd have to add support for the mk22dx too for my code (the bootloader is partially based off of the mchck stuff, but not entirely) if you want to use that (not really worth your time tbh). Currently I only support mchck's with an mk20dx128vlf5

Just get a Teesny 3.1 if you don't know which one (it's all around better). Basically, it's good to have something you know is working before attempting to port. I haven't seen any issues so far, but once in a while toolchain issues happen depending on your platform. That and you can get familiar with the debug interfaces that are available. Up to you though.

I can seem to find any of the dev kits on Holtek's site either (http://www.holmate.com/aspx/user01/ItemList.aspx Tools section).

So another option would be to use SWD to read the data off the flash (so you have a backup). Probably the easiest. And you'll have to do this anyways.

Once you get the data off of the chip, you'll then need to figure out (from the specs) how big the interrupt vector table is. Using a hex editor you should be able to identify the vector table in the bootloader (close to the beginning). Then look for similar pattern later (this should be the start of the image). This is because you need a second vector table for the firmware.
There's usually a bit of memory before the start of the vector table as well.

Using this info, you'll know how big the bootloader is. You'll need this for the linker script.
After this you can start trying to do stuff (usually start with a gpio). I wouldn't even use my code base at this point because you are just trying to get a bare-bones thing working.
It looks like there's sample code here (http://www.holtek.com.tw/english/docum/32bit_Flash_MCU/HT32F1655_1656.htm) which should help.

If you can get this far, then the rest will likely be much more straight-forward.

You'll definitely have to re-trace the matrix, but I have some tricks for this, generally you just need to figure out which pins are used for the matrix and then you can use the debug cli to actually figure out which keys are which.

As for which files to port. Look for lines with defined(mk20dx128vlf5), you'll usually have to do something around there.

Bunch of stuff here: https://github.com/kiibohd/controller/tree/master/Lib
https://github.com/kiibohd/controller/tree/master/Scan/MatrixARM (mostly the GPIO mappings, this might be tricky depending on how Holtek did it).
https://github.com/kiibohd/controller/tree/master/Debug A bit of stuff in here
https://github.com/kiibohd/controller/tree/master/Output This will be the trickiest. You may want to use the Holtek provided code for USB, then just port the hid descriptors instead. It all depends on how similar the hardware is to kinetis.

from controller.

Just a heads up that there's some notes on reversing the existing flashing software for the POK3R here:
https://geekhack.org/index.php?topic=72262
Came across your discussion while doing my own search to see if there's a supplier for the chips so testing could be performed.

This might be what you're after for a dev board: http://www.holtek.com/english/tech/tool/ESK32-300SK.htm It's for the 1656 not the 1655 but nevertheless shouldn't be a problem considering that both models share the same reference manual.

from controller.

Nice!
Yeah, I don't have any plans to do the porting myself, but I have no problems on support any porting efforts.

from controller.

I want to do this! Got the poker, got a mchck, and an stlink to use for swd.

Just haven't gotten around to it, if and when I dig into it I'll post here any updates.

from controller.

I've been trying to disassemble Ducky Mini firmware. I used SpritesMod's CM stuff slightly modified to get data out of mine. Just have a hard time figuring it all out. May be easier to open it and debug and start from scratch. :)

from controller.

Yeah, at some point it's often easier just to start over.

from controller.

I've been trying to disassemble Ducky Mini firmware. I used SpritesMod's CM stuff slightly modified to get data out of mine. Just have a hard time figuring it all out. May be easier to open it and debug and start from scratch. :)

did you ever make any progress on the Ducky firmware?

from controller.

Sorry, no. Was commenting some disassembly for a bit and shelved it. Was easier to make money and buy something else..

from controller.