Support for Key-combinations possible?

[userx14]

Good evening,
the Calibur's standard software seems to only support remapping an key with new functions like menu to mouse left. But for such a small keyboard something like fn+key for numpad or other functionality would be more useful. Do you know how this part of the drevo protocol works in which they download the keymappings on the keyboard / what did you use to reverse engineered the protocol?
Because I'm not sure if the current firmware can even support this I tried to find out which processor drevo is using, it says m103cb which reminded me of stm32f103cb, but it seems to be another cip because the quarz pins don't seem to match.
Greetings Beny

[Fail-0815]

Do you know how this part of the drevo protocol works in which they download the keymappings
on the keyboard / what did you use to reverse engineered the protocol?

Windows VM, passed the keyboard through to it and used Wireshark to monitor usb traffic.
I did not look very much into the protocol for macros yet, but i think that simple macros like fn+something should have been possible in the Windows tool. I'll have a look in the near future. (Expect updates within the next 2-3 weeks)

Because I'm not sure if the current firmware can even support this I tried to find out which processor
drevo is using, it says m103cb which reminded me of stm32f103cb, but it seems to be another cip
because the quarz pins don't seem to match.

I also tried to find out what kind of chip that is, but didn't find out anything more than that. I wanted to take a look into the firmware images Drevo supplied once to help identify what kind of chip this is. I'll update when i find something new.

[userx14]

I have tried to find out what the pinout of the microcontroller is: sorry for the awful drawing:

So the 5-pin port seems to be a programming port of some sort, and one of the pins should be something like a reset or boot configuration pin for programming.
The device with 8 pins on the left should be a flash memory.

[userx14]

So our microcontroller should have the following pins:
USB: 15,16
Oscillator: 44,45
Reset/boot: 46
GND: 1, 12
V+: 11,13,37
Serial for BT: 17,18
Programming Port: 35,36
Flash: 4,5

[Fail-0815]

So, in theory it seems like one could try to attach a UART Bridge/Serial Console to P3.
Since the firmware images i have are only for flashing via the supplied (windows exclusive...) flashing utility it's hard to know if these could potentially be directly flashed via P3 + UART. This would at least allow experimentation with the chip, since we could recover from a bricked state.

[userx14]

Yeah, I will try that later today and see if the chip outputs something during bootup...
I also inspected the .bin file and they seem to have a regular structure where 0x15 is appearing at the beginning of each line. The beginning and end of the file look interesting too...

[userx14]

Ok, there seems to be no communication at bootup at there pins. The mcu operates at 3.3V and both are on logic high if the mcu is powered.

[userx14]

But there is communication with the flash chip at bootup...

[Fail-0815]

But there is communication with the flash chip at bootup...

I'd suppose lighting and macro config are saved there and loaded on bootup

[userx14]

Very stange, I compared the pinout with nearly every microcontroller available on Mouser and no one matches. So as far as I can tell it can't be an ST, NXP, Atmel, Renesas, Cypress, Microchip, Silicon-Labs. Maybe an analysis of the .bin file would be more productive, I will try that now....

[userx14]

Ok I took a look on the .bin file. First of all the file only contains ascii characters. The characters coming after 15: seem to be the hex characters. I have stripped the number: from the file and converted it into hexadecimal.
71m.zip
I would guess it could be thumb assembly.
If it is this would be the first vew instructions:
0x0000: ldr r3, [sp, #0x274]
0x0002: str r1, [sp, #0x314]
0x0004: strh r0, [r7, #0x30]
0x0006: lsls r4, r3, #2
0x0008: subs r0, #0x55
0x000a: strb r1, [r7, #0x16]
0x000c: subs r0, r6, r2
0x000e: ldr r6, [sp, #0x68]
0x0010: cmp r7, #0xcb
0x0012: strh r0, [r6, #0xc]
0x0014: adds r2, #0x2a
0x0016: add r4, sp, #0x94
0x0018: str r7, [r0, r4]
0x001a: bgt #0xec
0x001c: stm r4!, {r1, r2}
0x001e: ldm r4, {r1, r3, r4, r5}
0x0020: strb r3, [r1, #0xd]
0x0022: asrs r7, r1, #0xe
0x0024: ldr r5, [r5, #0x44]
0x0026: subs r2, #0xa8
0x0028: subs r0, #0xac
0x002a: cbz r1, #0x50
0x002c: str r4, [r7, #0x34]
0x002e: cmp r0, #0x31
0x0030: str r6, [sp, #0x3e4]
0x0032: subs r2, #0x31

Another interesting find it that drevos functions for updating the keyboard, writing the rgb-configuration and so on are all located inside "UpgradeHWI.dll"/"DREVO72HWI.dll".
the interesting functions are called:
getHardwareVersion()
setKeyConfiguration(int,int,int*,int)
setKeyLight(int,int*)
setKeyboardLightArea(int *)
getKeyConfiguration(int,int,int*,int)
getKeyLight(int,int*)
getKeyboardLightArea(int *)
WriteKeyConfigurationToDev(HWND__ *)
ReadKeyboardVersion(wchar_t *)
DetectDevice()
and
WriteFirmwareToKeyboard(char *,int,HWND__ *)
most of them seem to call __createDev()

[userx14]

I might have found a match:
NuMicro NUC120 series seem to have a matching pinout:
Osc, Usb and I2C for flash seem to fit, it would be a cortex m0

[userx14]

So the other pin at the programming port is a reset pin...

Nuvoton even provides an example with an rgb keyboard and this microcontroller, this design features an 5pin programing header absolutely identical to the one found on the calibur...

I don't have an Nuvotec programmer, but acccording to some threads it should work with a stlink which I have laying around.

I wonder if the printing on the chip was just there to cause confusion and make reverse engineering more difficult.

EDIT: correct picture from numicro datasheet

[userx14]

Hmm, I attempted to find the usage of all pins of the microcontroller.
Pinout.pdf

---

---

Please ignore the upper left keyboard (it is the lower two combined and just for my reference), the other two keyboards depict how the keyboard switches are connected as a matrix.
The RGB-LED's follow a similar pattern but are connected to the shift registers and not the Microcontroller:
The shift registers are daisy chained according to the numbers (output to data input) and shift registers (2-5) control the RGB_Pins of the Led which are connected in the "Row-Like-structure" of the keyboard switches and shift register 1 + the pin "Transistor_Next_To_Shift1" seem to control the common pin of the LED's.

So it has an EEPROM, not a flash which seems identical to 24C256C.
Things I couldn't find out are:
-Usage of the "Voltage Divider" above the USB Voltage-Divider.
edit seems to go to Q1 an transistor next to the lipo 8dip protection circuit
edit2 could this be for battery level detection?
-Usage of the other grey pins, I suspect they are not connected but there could be traces underneath the chip.

For the 71-Key-version the additional switch is simply missing and the new switch uses the pins of the outer one.

If you want the ".svg" directly or find out what q1 is for, please let me know.