-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pro S RGB Support #1
Comments
Raspberry Pi 4 : ProS
Rebased openocd-ht32 with latest commits to fix some issues with raspberry pi: https://github.com/hansemro/openocd-ht32/tree/ht32f165x-dev Build:
openocd.cfg:
|
Pro S RGB firmware patch: https://github.com/hansemro/re-masterkeys/blob/Pro_S_RGB/binaries/Pro_S_RGB/patch.txt
EDIT Sept 8, 2022: Fixed and tested firmware patch |
Some USB packet captures: 1: Plugging in keyboard 2: Firmware upgrade (1.2.2 to 1.2.2) via OEM software 3: Firmware upgrade from fake version (1.1.9) to 1.2.2 via OEM software: no major difference |
python script to get current firmware version from Pro S: RGB Dependency: pyusb get_version.py: #!/usr/bin/env python3
import usb.core
import usb.util
dev = usb.core.find(idVendor=0x2516, idProduct=0x003c)
if dev is None:
raise ValueError('CM Pro S not found')
else:
print("CM Pro S found")
if dev.is_kernel_driver_active(1):
try:
dev.detach_kernel_driver(1)
print("kernel driver detached")
except usb.core.USBERROR as e:
print(f"Could not detach kernel driver: {e}")
exit(1)
try:
usb.util.claim_interface(dev, 1)
print("Claimed usb device")
except Exception as e:
print(f"{e}")
exit(1)
#ver_req = [ 0x01,0x02,0xdf,0xfc,0x00,0x30,0x00,0x00,0x3d,0x30,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0
x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
,0x00,0x00,0x00,0x00 ]
ver_req = [ 0x01,0x02 ]
dev.write(0x04, ver_req)
out = dev.read(0x83, 64)
out = "".join(chr(x) for x in out)
print(f"{out[4:9]}")
usb.util.dispose_resources(dev) output:
|
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
Correction: Pro S RGB seems to implement/borrow functions in pok3r and cykb protocols. For example, |
Good and bad news: erase command works for clearing version and firmware data.... In my attempt to write firmware with flash erase step (in my fork of pok3rtool: https://github.com/hansemro/pok3rtool/tree/cooler-master-dev), I noticed that cooler master can no longer be detected over USB and can not function as a HID device. I was able to set version successfully, but it seems firmware region could not be written to. |
Shorting SEL2 to boot into bootloader mode allows the keyboard to be detected, but not with cooler master VID/PID/IPID.
Not sure what can be done to reprogram firmware without erasing bootloader... EDIT: |
Modified SVD with some changes to fix overlapping peripheral regions: HT32F1653_54.svd.zip SVD Source: https://web.archive.org/web/20220827045212/https://mcu.holtek.com.tw/pack/Holtek.HT32_DFP.1.0.41.pack |
Fixed firmware writing with my fork of pok3rtool with hansemro/pok3rtool@11b822d, managed to dump flash from another Pro S RGB, and recovered my previously dead board with stock bootloader! Flashing patched firmware (from 1.2.2):
|
Added initial schematic drawing after a few days of tracing: hansemro@35a5ebb |
Added initial QMK support (key switch and USB support only): https://github.com/hansemro/qmk_firmware/tree/prosrgb_dev |
MBIA043 RE notes:These results were discovered from firmware disassembly and testing in QMK. QMK test branch: https://github.com/hansemro/qmk_firmware/tree/prosrgb_mbia043_testing2 InstructionsInstructions are determined by the number of DCLK rising edges while LE is asserted. For instructions that read data from shift register, the falling edge of LE must occur shortly after the final data entry gets shifted. Data Latch: 1 DCLK rising edgeMoves data from shift register to buffer. Overall Latch: 2 DCLK rising edgesMoves data in buffers to comparators. (Undocumented) Read Configuration: 4 DCLK rising edgesMoves 10-bit configuration data to shift register. Configuration:
(Undocumented) Enable Write Configuration: 18 DCLK rising edgesEnables Write Configuration instruction (if it is the next instruction). Used by v122 firmware. (Undocumented) Write Configuration: 8 DCLK rising edgesMoves data from shift register to (undocumented) configuration register. Used by v122 firmware to configure each MBIA IC to 0b0000001100. RoutinesShifting dataOn every rising edge of DCLK, the shift-register shifts in data from SDI and out of SDO. This includes cases when LE is asserted high (to call an instruction using data in the shift-register). v122 Sending an instructionSet LE high until the requisite number of DCLK rising edges has been met, then set LE low. Whatever data is in the shift-register on the final DCLK edge is used for the instruction (and not a DCLK cycle later). v122 Setting grayscale valuesA grayscale value for each channel must be set (starting from channel 16/OUT15) when updating comparator values. For each channel, a (10-bit) grayscale data is shifted in with LE asserted only for the last bit (Data Latch). After latching data for the final channel, send Overall Latch command. Note that cascading MBIAs essentially become an extended shift-register, so the same general steps above apply to this case but with N * 10-bit data to shift for each channel. v122 mbia_shift_RGB_from_sram (writes RGB data to buffers for single row): https://github.com/hansemro/pok3r_re_firmware/blob/8346ba6d6a77e60094a02dcac3b5c8559cb7bf75/disassemble/cmprosrgb/v122/cmprosrgb_v122.txt#L8413-L8490 v122 bftm1_intr (commits buffers to comparators): https://github.com/hansemro/pok3r_re_firmware/blob/8346ba6d6a77e60094a02dcac3b5c8559cb7bf75/disassemble/cmprosrgb/v122/cmprosrgb_v122.txt#L657-L708 TimingFor MBIA043 at 3.3V, DCLK has maximum allowed frequency of 25 MHz, so use the appropriate number of NOP delays to operate below this limit. (e.g. For ARM core running at 72 MHz, 3 NOPs are required to run at/below 24 MHz). |
Dimming test (shortened cycle length to reduce video length) with QMK. prosrgb_mbia_cycle_test.mp4 |
Per-key lighting on QMK: prosrgb_mbia_rgb_driver.mp4 |
Keyboard (with QMK) hardfaults after enabling Flash Memory Security Protection bit (OB_PP[0]). |
Added a new openocd branch to enable security bits (which will be used to debug lockup when security is enabled): https://github.com/hansemro/openocd-ht32/tree/ht32f165x-security-test
|
While keyboard is locked, things you can do in openocd:
Some things you cannot do while locked:
|
CN2 header:
SEL1 header:
SEL2 header:
So far, very similar to POK3R RGB. I will update with more details as I find them.
Tasks:
[0x1, 0x2]
command[0x0, 0x8, ...]
command[0x1, 0x1, ...]
command[0x4, 0x0]
command[0x4, 0x1]
command[0x3, 0x0]
command[0x12, 0xff, ...]
[0x12, 0xff]
commandThe text was updated successfully, but these errors were encountered: