Supporting the Tt eSports Poseidon Z RGB

[fonix232]

I've purchased this keyboard a while back on a really good deal, and while it's a fine mech, the software lacks quite a lot - for example it does not run on macOS.

Many have tried to reverse their USB protocols and somewhat working pieces of code are available, but it does not help the fact that the whole thing's firmware is a big steaming pile of manure.

I'd love to see some custom development being done on it, and I have the keyboard at hand, however I have little knowledge of how QMK works, and if it is even possible to run it on the Z RGB. However I'm optimistic that it can be done, and if someone lent me a helping hand, even some guidance (finding out the proper mapping of the stuff, the controller type and how to program it, etc.) would be helpful, and I'd gladly test it out.

Do you have any resources that would help me out, at least to get a base config up and running?

[drashna]

It looks to be an ARM Cortex-M0, and there are a couple of boards that use it (the Ergodox Infinity, I think).

So the question is, how easy is it to flash?

And somebody would have to map out the matrix, and create the code based on that info.

So, it may be possible.

[fonix232]

Yes, I was thinking of doing just that, however while I have the keyboard, I have no knowledge of doing these.

Flashing is a bit of an issue due to the stock firmware using a proprietary protocol, but I think I can reverse the tool used and create a minimal flashing tool that would upload QMK (or a stock firmware). However since QMK is so much more feature-rich (and has working configurators on all platforms), I doubt anyone would actually go back to the stock firmware if QMK, TMK or any other open source project provided support for it.

(Also sorry for the late reply, for some reason GitHub failed to notify me about the response)

[fonix232]

Okay, did some research.

The keyboard uses the NPC LPC11U35F/401 controller, and 3x MB15042GP B1P141CFHB for LED control (one controller for each color channel of RGB).

The switches themselves seem to be on a standard diode grid, but pin mapping is questionable - easiest would be if I could deploy a test firmware that pushes the pin of the key I pressed to the PC it is connected to.

I think I'll make some slight changes to the keyboard itself, mostly for my use - a better casing (stock is good, but I have no use for the cable channels), replace the built-in cable with a USB port (preferably a Type-C port), and of course the custom firmware flashing.

[drashna]

Any progress on this?

[fonix232]

Unfortunately no, as I've been busy with work. Will try to take a look around inside the keyboard in the following days, though.

[drashna]

Not a problem. It's just been a bit, and I wanted to touch base. (I've been going through all of the issues).

And take your time, no rush!

[fonix232]

The main issue here is the no-access to the stock firmware, and the flasher being closed source. Unfortunately not many tinkerers have bought this keyboard, and such there hasn't been much progress on any kind of customization. I'm actually thinking about selling it and buying something more standard (preferably with replaceable switches).

[stale[bot]]

This issue has been automatically marked as resolved because it has not had activity in the last 90 days. It will be closed in the next 30 days unless it is tagged properly or other activity occurs.

[drashna]

To be honest, given the time, and lack of apparent issue, and the technical hurdles, closing. Sorry.

[bpmcgill]

I wish I had know that alternative firmware was a thing. I have 2 of these keyboards and just enough programming knowledge to be dangerous. Is there anyway we can get this opened back up, because the firmware on this is absolute trash.

[fonix232]

@bpmcgill I was unable to rip the stock firmware during update, hence the lack of progress... However if you do manage to get qmk running, I'm a willing test subject! I've replaced this keyboard with a Drop CTRL for main use already, so no big loss if it gets stuck in a half-working state.

[bpmcgill]

I have the hex file from 2 different firmware update packages... I will talk to the firmware engineers here at work to see if they know how to dump the firmware.

[fonix232]

If you got the HEX files, that's a good start - I'd probably begin with dropping them in IDA to see how it's made, if there's any open source bits that can be identified (I'd be surprised if Tt decided to build a completely custom solution, as the controller on this board is a fairly standard one with lots of open bootloader and whatnot), and start debugging from there.

Could you upload the HEX files here?

On Thu, 23 Jan 2020, 17:06 bpmcgill, notifications@github.com wrote:

I have the hex file from 2 different firmware update packages... I will talk to the firmware engineers here at work to see if they know how to dump the firmware.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/qmk/qmk_firmware/issues/2285?email_source=notifications&email_token=AAC2ZB2M342XIMXVW73URV3Q7HFBFA5CNFSM4EMNH4E2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJYCT2Q#issuecomment-577776106, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAC2ZBYPIGS4OOO6UK7QD53Q7HFBFANCNFSM4EMNH4EQ .

[bpmcgill]

Here are the firmwares... The talk with the FW guys went pretty well, they want me to open the keyboard and look for a JTAG or serial header. The alternative is to load up USB spy to see what command sets the keyboard into boot loader mode.

Poseidon_Rgb_V40.zip Poseidon_Rgb_v51.zip

[bpmcgill]

I thought I had posted this earlier. Here is the datasheet for the flash chip. I was also able to locate serial port pins on the board that may aid in the FW dump.

Flash Chip Datasheet

[bpmcgill]

Here is the packet capture of the FW update. I am not sure if this is going to help anyone... Hopefully this will contain the magic that allows us to put the device in FW update mode...

TT-Poseidon Z RGB USB FW UPDATE CAP.zip

[bpmcgill]

I have made 0 progress on this, I just don't have the knowledge to make any headway. I can tell from the packet capture that a command is sent to the keyboard, the keyboard reboots into a "DFU" like mode and a new device is enumerated (ostensibly the firmware flash device). The firmware is programmed and another command is sent to reboot the keyboard into normal operation.

Beyond that I am not sure what to do with the firmware. I don't know IDA so dropping the firmwares that I was able to extract from the installer packages didn't reveal anything to my untrained eye.

So if anyone wants to look at the USB packet capture above, you will see the command to send to the device to get it into bootloader mode, and then someone with some knowledge of ASM would be able to tell what the firmware is doing. There is very clearly labeled pads on the board that correspond with a serial port, I may get a crap keyboard to use in the interim and solder some header pins onto my board and see if I can send any commands to the board with putty.

[bpmcgill]

So I bought a new keyboard for work, and when it arrives I will begin on hacking this thing. It is a few weeks out due to corona virus issues. I am looking at the possibility of de-soldering the daughter board that the micro-controller is on and replacing it with a proton c or similar.

[taronhov]

Hi, I am very excited with your initiative to develop a QMK support mechanism for LPC11U35F MCU based boards. And doing that through official firmware update routine (should be a "USB DFU" kind of thing) is definitely the preferred (non-invasive) and easiest method... I have ordered a G.Skill KM780 keyboard with the same MCU, and I also want to get rid of their crappy software/firmware and leverage the whole potential QMK provides! As soon as it arrives (probably in 2 weeks), I want to jump into development and help you to accelerate the things.

P.S. But the easiest method I see (from hardware engineer perspective :) ) here is just to buy a new MCU and freshly flash it with QMK firmware:

---

https://eu.mouser.com/Search/Refine?Keyword=LPC11U35F

---

Yes, it will require some soldering (and a heat-gun to de-solder) but ,just in case, as a "last hope" solution...

[tzarc]

Just an FYI, neither ChibiOS nor ChibiOS-Contrib have support for the LPC11 series chips:

https://github.com/qmk/ChibiOS/tree/master/os/hal/ports https://github.com/qmk/ChibiOS-Contrib/tree/master/os/hal/ports

In order to get support to QMK added, you'd need to get support for LPC11 added to ChibiOS-Contrib before we'll accept boards that use this MCU.

There is also an expectation that the contributor of that MCU support keeps it up-to-date -- we've been forced to start implementing a deprecation policy for boards that aren't kept up to date with QMK's dependencies.

[taronhov]

Hi @tzarc , Thanks for clarifications and provided information! OK, I will dig deeper into issues related to LPC11 series support in ChibiOS and see what can be done there.

[stale[bot]]

This issue has been automatically marked as stale because it has not had activity in the last 90 days. It will be closed in the next 30 days unless it is tagged properly or other activity occurs. For maintainers: Please label with bug, in progress, on hold, discussion or to do to prevent the issue from being re-flagged.

[stale[bot]]

This issue has been automatically closed because it has not had activity in the last 30 days. If this issue is still valid, re-open the issue and let us know.

[hanetzer]

Just wanna put in some info for you guys if you're still slightly interested in this. The LPC11U35 MCU has a unique flashing (and dumping, depending) mode built into its bootrom. if you hold PIO0_1 low during power on it acts as a usb flash drive with a file, firmware.bin in it. Depending on the level of code read protection configured (done by writing one of four magic values to flash addr 0x2fc) you can copy this file out, and writing a new file will program the keyboard. I know this as the roccat vulcan 12x aimo keyboards use the same soc, and the manufacturer was kind enough to not enable any CRP and provide two test points, one to GND and one to PIO0_1 near one another to be able to easily invoke it.

[evankanderson]

It looks like ChibiOS-Contrib now has support for the LPC11U35F, it appears: https://github.com/qmk/ChibiOS-Contrib/tree/master/os/hal/ports/LPC/LPC11Uxx

I have a spare one of these kicking around and might be willing to put a little time into bringing it up if there are directions somewhere handy. (What to do / how to build)

[arnieelkins]

It looks like ChibiOS-Contrib now has support for the LPC11U35F, it appears: https://github.com/qmk/ChibiOS-Contrib/tree/master/os/hal/ports/LPC/LPC11Uxx

I have a spare one of these kicking around and might be willing to put a little time into bringing it up if there are directions somewhere handy. (What to do / how to build)

Evan, I am a disabled software engineer with two of these keyboards, one with blue LEDs and one with RGB. I have no clue about firmware or hardware hacking in general, but I have nothing but time on my hands and a vested interest in getting these things to stop ddooubliiing or mmoooree. I have less than zero money, but these were great keyboards whenI bought them, and they have all the switches, so if I had to, I would replace the controllers with something that has reasonable support.

• Either way, new software and/or hardware, I would VERY much like to get these working. I used to play with C 30 years ago, and I love Python, and software does not cost anything but time, which I have in abundance. I really need these to work, and I always suspected the firmware, but TT replaced the RGB board, and it started having issues after a month or so.

Anyone know how to A) Make the current hardware work reliably, or B) replace the controllers with something that has software I can modify?

Arnie Elkins arnie.elkins@gmail or baronettaltos@protonmail.com