Logitech G413: pinout and matrix

[user2021]

Traced the Logitech G413 so I could flash QMK on it. Due to the µC shortages and the original one being read protect level 2 this project is indefinitely postponed.
None the less somebody else might find this information useful.

Schematic (dirty/not cleaned):
https://oshwlab.com/Xenons/logitech-g413

Disassembly:
Way too many screws and keycap remover highly recommended for Romer-G. For guidance look up this well-documented process.

Programming:
Everything is nicely available at test points. The last needed connection can be accessed at JP223 (JP94 on the schematic).
As a side effect of the µC needing replacement, an upgrade to pin-compatible STM32 with DFU ( might be possible eliminating the need for an ST-Link. The button between VDD and BOOT0 can easily be soldered across R95 and C1 (on the schematic).

Pinout:
Again look at the schematic as there is everything labeled.

Matrix:
Look at the picture.

In case someone completes the project feel free to drop the link to the QMK config down in the comments.

[Gondolindrim]

First things first: we need to know what MCU it uses and what is its pinout (i.e. what pin is connected to what) so we can determine whether we can use an STM32 replacement.

Unfortunately most of the times this is not possible, even among the STM32 family itself; most cases of cross-compatibility are specifically designed for that (like F401 and F411).

[user2021]

STM32L100
From my browser history, it might be an STM32L100R8T6.

Haven't looked into compatible parts since there isn't any point right now as I am not willing to spend $20 or so on just a µC for this keyboard. Looking at the current situation it is unlikely I will revisit this earlier than summer 2022.

Btw. If more information about the crystal layout is needed I can check the G512 PCB which still has these parts on it (just like the G910 based on the same STM32L100 [higher complexity due to the coprocessing for the RGB]).

[Gondolindrim]

I'd fully reverse engineer the keyboard before attempting to swap components out

[user2021]

The issue is you can't reprogram this IC as they have set read protection to level 2. There is an attack utilizing a bad design decision by ST which breaks level 2 down to level 1 (at this point you could also dump the firmware). The problem with this attack is that it requires decapping the IC.

Besides the crystal, there is everything you need and for the crystal, you need anyway to open up the keyboard for programming.

[Gondolindrim]

There is a little more to it than just figuring out the firmware.

If the keyboard supports dynamic keymaps, then it should have an EEPROM; if it does not, then it probably emulates it in the flash memory. I don't know L100 enough to be certain, but from what I read in datasheets and reference manuals, it does not support that. So if you want dynamic keymapping and the keyboard does not have external EEPROM, you need to use a uC that supports EEPROM simulation and is QMK supported -- F072 and L072 come to mind, the former being able to simulate EEPROM and the latter having embedded EEPROM.

If you can do neither, than you prbbaly won't have XMP/VIA support.

What pin is used for the backlight? QMK cannot use TIM2 by default because ChibiOS uses it for tick timer. Does it use SPI? What kind of driver? QMK supports WS2812 in all three configurations -- SPI, PWM and bit-bang. Does it have PKRGB? If yes, what's the implementation? Is it an I2C chip?

That the stock firmware is read-protected is not surprising, as that is pretty standard for large-scale consumer electronics. and there are plenty exploits you can use; the STM32F1xx family comes to mind, as there are plenty vulnerabilities relating to debug interface, load stacks and exception handling (see for instance https://www.usenix.org/system/files/woot20-paper-obermaier.pdf).

[user2021]

Had a Logitech G203 open for repair: STM32L100R8T6
Maybe look at the picture: There is nothing. No addressable lightning, no EEPROM.  Not sure if I labeled the pin but even if not you can identify it within seconds.

If somebody already reversed engineered the official update procedure link it. I don't feel like potentially dealing with unusual protocols, checksums, or signed code/firmware.