Open hansemro opened 1 year ago
$ ht32-dfu-tool info
Claimed interface
Getting device info...
Model: HT32F1654
Version: v100
Page size: 1024 B
Flash size: 64512 B
Flash security: true
Option byte protection: true
Page protection: 0xfffff000 0xffffffff 0xffffffff 0xffffffff
Finally managed to port QMK for Pro M White + RGB! These two were very hard to get my hands on, especially the RGB variant.
The primary things holding me back from upstreaming my ports:
https://github.com/hansemro/ht32_usb_dfu partially accomplishes 3 but does not currently avoid jumping to empty regions of flash. If the device does manage to get locked up, just short BOOT0 to ground and reset to reach DFU mode.
Resolved flickering (1) for POK3R RGB by leveraging double buffering in https://github.com/hansemro/qmk_firmware/commit/06a38cd54c2c9ea3d95eee83a7f3e33ef9c509a2, where back buffer is used by rendering tasks and the front buffer is used for flushing completed color data to MBI buffers.
Update: flickering fixed for Pro M RGB in https://github.com/hansemro/qmk_firmware/commit/0764c102f298654a10ea5f0ebc6943b58a0c66e3
Hi there! I have a stock Pro M RGB. Before I start tinkering with anything, are there any dumps that would be useful for the RE work? I see there's a TODO on dumping the spi flash.
I've been having a look at the install instructions - is there no way to install the custom FW with the stock update mechanism? I'm not looking forward to ripping the feet off my keyboard :P
Edit: another question - have you dumped firmware from any of the pro m rgb update binaries? Getting junk from them so far, and I can't find V1.04 referenced in updatepackage
are there any dumps that would be useful for the RE work? I see there's a TODO on dumping the spi flash.
SPI flash dumps are not particularly important unless you want to fully RE the stock firmware and make sense of the data written/read from external flash. It may also be useful for restoring from backup.
Most of the pending RE work was found to not be necessary after RE'ing Pro S RGB and Pro L White models.
have you dumped firmware from any of the pro m rgb update binaries?
Yes, the trick here is to extract FWUpdate.exe from masterkeys_pro_m_vX.XX.exe/bin/Setup/File/FWUpdate/
. You can use 7z to extract this file. Afterwards, you should be able to use pok3rtool to pull the application firmware binary from FWUpdate.exe.
is there no way to install the custom FW with the stock update mechanism? I'm not looking forward to ripping the feet off my keyboard :P
Unfortunately, no other way has been found to avoid opening the keyboard and unlocking the processor. It may be worth investigating what triggers a hard fault when it boots into QMK or any other custom FW. The challenge here is that flash security also disables SWD debugging and booting from SRAM.
For that particular disassembly step, you only need to partially lift the left side of the rubber feet (with a tweezer) to expose the screw. For Pro M RGB, you only need to do this for the two upper pads (furthest away from you).
HW info:
CN2 header:
SEL1 header:
SEL2 header: short to enter ISP
Tasks: