[Feature Request] support durgod/k320 with LPC11U24F #15096
Comments
|
@putyn Was this a base model (no leds), a corona (white leds), aurora (red/blue leds), or nebula (rgb leds)? The K320 Nebula I have uses the LPC11U35F MCU, but I haven't had the time to dig into it much. |
|
@dkjer it is the base model (no leds), however the PCB has holes under the switches for leds and there is an unpopulated IC on the board which might be a led driver. |
|
@dkjer anything I can do to help with adding support? |
|
@putyn Unfortunately I don't have a lot of free time currently to investigate this, though I might be able to take a look over the holidays |
|
@dkjer no worries. In the meantime, I started reading about this MCU family from NXP, basically U24/U35 are the same 11Uxx family and they have among others things a ROM USB Bootloader, which when activated it will mount the internal flash as an USB Drive and allows for easy firmware upgrade. I managed to compile a hello world program (toggling the keyboard onboard leds) using the mbed online compiler and successfully flash it on the board, next is to get the same hello world but build on top of ChibiOS or even better directly via the QMK firmware. I have also found this project OpenKemove which forks the QMK project to add support for a keyboard based on LPC11U35. |
|
@putyn Awesome! If you can get ChibiOS running on there that would be excellent |
|
@dkjer I got the leds blinking using the QMKs fork of ChibiOS only a memory setup file was needed since U24 has less flash compared to U35. |
|
I worked on the LPC11U35 port of ChibiOS, most things works except maybe I2C which the kemove board did not use. Let me know if you need help, feel free to find me on discord codetector#7727 |
|
@Codetector1374 your work on porting ChibiOS this is the whole reason I'm event attempting to port QMK on the LPC11U24, so thanks for that! At the moment I'm trying to get familiar with how one is supposed to setup a new keyboard, qmk new-keyboard doesn't work for ARM based keyboards. Any guide on this topic? |
|
Hi, sorry for the late reply
Codetector1374@a606278
This is the commit where I added support for k320 stm32 version (I just did it myself a while back didn’t know there’s work on porting it already lol)
But it should be good reference in terms of what files you might need to create / copy to bring up a board
…On Nov 20, 2021, 3:41 AM -0500, Vlad Co ***@***.***>, wrote:
@Codetector1374 your work on porting ChibiOS this is the whole reason I'm event attempting to port QMK on the LPC11U24, so thanks for that!
At the moment I'm trying to get familiar with how one is supposed to setup a new keyboard, qmk new-keyboard doesn't work for ARM based keyboards. Any guide on this topic?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
@Codetector1374 thanks you! yes that definitely helps, I already had a go at at it, but make complained that it didn't have a target. any pointers on the easiest way to reverse engineer the keyboard matrix? |
|
There’s probably no “easy” way. Just take a multimeter and a blank keyboard layout measure the continuity and slowly map it out. It might take quite a few hours. I had a friend help me record and I measure took us like ~2 hours to do a board
…On Nov 26, 2021, 4:24 PM -0500, Vlad Co ***@***.***>, wrote:
@Codetector1374 thanks you! yes that definitely helps, I already had a go at at it, but make complained that it didn't have a target.
any pointers on the easiest way to reverse engineer the keyboard matrix?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
@putyn if it's a K320, there's a good chance that the PCB in your board will have the same matrix layout as ones manufactured later. You can confirm by comparing it with the matrix diagram that I made when I was comparing my circa-2019 ANSI K320 boards with my circa-2019 ANSI K310 boards. I made a "ditaa" diagram and kept a copy of it here https://github.com/tylert/tylert.github.io/blob/master/source/hid/keyboard_matrix_durgod_k3x0.txt ("ditaa -r -o foo.txt foo.png" to generate a bitmap from the ASCII). While you are probing the matrix, just remember that the diodes will appear to be "disconnected in one direction" so make sure you test around a bit first using your multimeter or continuity-tester to get a feel for what is and is not "actually connected" together. Again, my expectation is that your K320 matrix is very likely to be the same as the ones used on the newer versions of the K320 (as shown in my "ditaa" diagram linked above)... however, this is also just a guess on my part so you'll have to confirm this fact. I would also grab the pinouts from the datasheet for the uC used on your board and confirm that they match this diagram as well that uses a slightly different uC. Good luck and please report back if you get stuck. |
|
@putyn did you have a chance to work on this yet? I just bought a k320 recently, hoping to also play around with qmk, but it turned out to be the lpc11u24f model. I have a "nebula" one, the one with the RGB lights, so I can help with testing if that helps! |
|
@tylert, @Codetector1374 thanks for the details, I will keep you posted with the update. @iliazeus not yet, but I do want to start in the near future at least with getting qmk built for the target mcu and reverse engineering of the matrix later. |
|
ok so after having spent some time editing files I have managed to compile qmk, I will fork the main repository and push my changes, stay tunned |
|
ok so I have flashed the firmware I built, it doesn't enumerate in windows, still probably something to configure for USB missing but I got a led to turn on, so at least the boardInit is executed. |
|
@putyn Awesome work! Do you have a branch with your progress so far? I would love to get running QMK on my LPC11U35F K320 Nebula. It is interesting that Durgod seems to have been using a mix of LPC11U24F, LPC11U35F and STM32 for the same keyboard... My K320 Nebula with an LPC11U35F has the following PCB markings on it (assuming second line is just manufacture date): @iliazeus I am curious what the PCB markings say on your K320 Nebula with the LPC11U24F? |
|
@dkjer -- not yet, I need some changes in the ChibiOS-Contrib repository also and I saw this is added as a submodule log story short I got sidetracked reading about git/submodule and how to setup everything will report back when I have the changes pushed to my qmk fork stay tuned! |
|
@dkjer both qmk and ChibiOS-Contrib are forked, I have pushed a k320_lpc branch to both of them. I also changed the chibios-contrib submodule to point to my fork not entirely sure if I did that correctly. |
|
Sorry I kept you guys waiting. I've only just had the time to open up the keyboard again. @putyn here are my pcb's photos: https://1drv.ms/f/s!AlpEiB1-lwyGixvTU8KYYjvM9NC6 @dkjer my markings are: And it turns out, mine's also a LPC11U35F. I think I misread the text the first time. |
|
ok so I have been fiddling around with this for the last few days learned a couple of things:
@iliazeus - thanks for the photos. Can you also take a picture with the ICs driving the leds? |
|
@putyn seem to be these ones, if I understood correctly. There are four of them on the PCB. https://1drv.ms/u/s!AlpEiB1-lwyGiyEHliVqmAjAaqGK (I've also added this photo in a folder with the rest). |
|
@iliazeus that appears to be an IS31FL3731 led driver, the good news is that I saw support in QMK for it, the not so good news is that that is uses I2C to communicate with the MCU and at least for the LPC11Uxx family there isn't yet an I2C driver for ChibiOS. on other news I got the keyboard to enumerate in windows and linux 😃 the issue was with one configuration for the ChibiOS kernel which I copied without knowing from the port for k320 with STM32 (I haven't yet pushed the update to my fork but CH_CFG_ST_FREQUENCY should be set to 1000 not 10000 as it is now); however as soon as the board is flashed and plugged into the computer… it sort of makes the host unresponsive, host keyboard becomes unresponsive also some keypresses are sent by the k320 I suspect that this is due to the fact my matrix is not yet populated and I'm using some dummy pins to make compilation work will investigate more... |
|
First congrats. I can add i2c to chibiOS for the LPC family that is fine. It’s not very difficult. It might take some time to get all merged upstream and the down to qmk etc. but I’ll keep y’all updated |
|
it works, this comment is written on the k320 w/ LPC11U24 running QMK! something I'm still unsatisfied with is that for flashing I need to manually activate the USB ROM Bootloader I had some hopes with AN11305 where it is mentioned that you can call the bootloader from the user application, but so far I haven't been able to do that. The other option is to use @Codetector1374 usb dfu bootloader implementation but that will consume space. Any other idea? next steps would be to have this merged back into qmk/chibios-contrib right? |
|
I’ve actually tried the calling the USB ROM loader in application route. It works but super unreliable. (At least that is the case on another keyboard using the same chip) I would not recommend. You will need a boot loader of some sort so :) either the one in rom or you will have to consume some space. I’d say on a 64K chip using 8k for a boot loader is not so bad |
|
The thing is u24 only has 32K flash and about half is already taken by
basic functionality if we take another 8K for the bootloader we will
quickly run out of space.
On the other hand I have found some mentions about an usb-dfu
implementation with the USB ROM API (presumably this will consume less
space) however I haven't been able to actually find the example as the
links appear to be dead😃
…On Tue, Jan 4, 2022, 00:41 Yaotian Feng ***@***.***> wrote:
I’ve actually tried the calling the USB ROM loader in application route.
It works but super unreliable. (At least that is the case on another
keyboard using the same chip) I would not recommend. You will need a boot
loader of some sort so :) either the one in rom or you will have to consume
some space. I’d say on a 64K chip using 8k for a boot loader is not so bad
—
Reply to this email directly, view it on GitHub
<#15096 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAH4XNMSLPIJKWYDBZIWMN3UUIQYVANCNFSM5HVETIMA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
ahhh maybe I can look into implementing something like that. I am currently trying to setup my tool chains again. Recently moved to windows and now realize that getting openocd to compile on windows is not trivial. |
|
This looks really interesting. I have the u68 in a Corsair keyboard. As far as I know they are pretty similar apart from the u68 having USB internally already if I understood that correctly and larger flash / ram sizes. |
|
@crashniels at a first glance at the product sheet, u68 has newer cortex-m0+ (but according to ARM it should be backwards compatible with cortex m0) compared to u2/3x. The entire LPC11Uxx series has USB but only u2/3/6x also have USB ROM drivers but this doesn't really matter for QMK as the USB implementation in ChibiOS doesn't use the ROM drivers. Until I can get the changes back into qmk/chibios you can use my fork to get hacking 😄 |
|
Could this work also be used to port qmk to the Razer Blackwidow Ultimate Sleath (2016) that has the same microcontroller (LPC11U24F)? |
Answering my own question: maybe? So far I've forked your fork and made the necessary changes to get it to compile (beyond actually doing the keymap...). Then I managed to boot the keyboard into its usb mass storage mode and "copied" the "original" firmware off of it and dropped the new firmware onto it. (Turns out CRP1 was enabled and so I ended up copying a blank file). And the keyboard just reboots to the ISP now, meaning the firmware either didn't work, or some other problem (I've tried two different checksum programs). Trying to drop a simple blink arm mbed example didn't work either. Without the firmware I guess I need to get something working on this board for it to work at all, as I don't think the razer updater is going to fix it. I love hacking hardware :). Thank you for all your work on this! |
|
The work done for k320 should give you a pretty good idea on what you need to change to get QMK on your razer. After flashing the blinky binary, is CRP still 1? If its still 1 try the following:
this is taken from AN11305. Most likely your blinky failed because it was not programmed properly :) |
|
I'll have to try running the software on a windows machine soon (though i dont know if it'll work as it requires the keyboard to be plugged in, probably running proper razer firmware with the correct usb ids) After flashing the blinky, it went from saying CRP1 ENABLD to CRP DISABLD (as the usb mass storage name), which is good? Except no matter what firmware i flash (mbed online compiler, platformio example projects, qmk firmware) rebooting the device just goes back to the ISP mode. Possibly bricked the board, which would suck. |
Yes it will probably not work, but you only need the original binary.
Yes, also good. What I believe happens is either a misconfiguration in the compiler (the combination after LPC11U24 defines how much flash it has, make sure whatever you set in the tool matches with your hardware) or the PIO0_1 kept low after flashing; PIO0_1 needs to be high after flashing to execute code, otherwise ISP will be called again. |
What I was trying to say is that the program won't download the firmware until it detects the proper keyboard detected, and as mine's not going to do that, I don't think it's possible for me to get the original binary firmware. I briefly investigated creating a "fake" hid keyboard device, but didn't really get anywhere with it.
I soldered a wire to PIO0_1 to manually pull it high and it still fails to boot. I've also made sure it's the correct version and flash amount (/401). Maybe Razer built in a killswitch to stop alternate firmwares with a signing key or something? I don't know. Here's the Apr 16 18:34:07 nobody-t14 kernel: usb 4-2: new full-speed USB device number 11 using xhci_hcd Apr 16 18:34:07 nobody-t14 kernel: usb 4-2: device descriptor read/64, error -71 Apr 16 18:34:07 nobody-t14 kernel: usb 4-2: device descriptor read/64, error -71 Apr 16 18:34:07 nobody-t14 kernel: usb 4-2: new full-speed USB device number 12 using xhci_hcd Apr 16 18:34:07 nobody-t14 kernel: usb 4-2: New USB device found, idVendor=1fc9, idProduct=000b, bcdDevice= 7.04 Apr 16 18:34:07 nobody-t14 kernel: usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Apr 16 18:34:07 nobody-t14 kernel: usb 4-2: Product: LPC1XXX IFLASH Apr 16 18:34:07 nobody-t14 kernel: usb 4-2: Manufacturer: NXP Apr 16 18:34:07 nobody-t14 kernel: usb 4-2: SerialNumber: ISP Apr 16 18:34:07 nobody-t14 kernel: usb-storage 4-2:1.0: USB Mass Storage device detected Apr 16 18:34:07 nobody-t14 kernel: scsi host0: usb-storage 4-2:1.0 Apr 16 18:34:07 nobody-t14 mtp-probe[73093]: checking bus 4, device 12: "/sys/devices/pci0000:00/0000:00:08.1/0000:07:00.3/usb4/4-2" Apr 16 18:34:07 nobody-t14 mtp-probe[73093]: bus: 4, device: 12 was not an MTP device Apr 16 18:34:08 nobody-t14 mtp-probe[73095]: checking bus 4, device 12: "/sys/devices/pci0000:00/0000:00:08.1/0000:07:00.3/usb4/4-2" Apr 16 18:34:08 nobody-t14 mtp-probe[73095]: bus: 4, device: 12 was not an MTP device Apr 16 18:34:08 nobody-t14 kernel: scsi 0:0:0:0: Direct-Access NXP LPC1XXX IFLASH 1.0 PQ: 0 ANSI: 0 CCS Apr 16 18:34:09 nobody-t14 kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0 Apr 16 18:34:09 nobody-t14 kernel: sd 0:0:0:0: [sda] 68 512-byte logical blocks: (34.8 kB/34.0 KiB) Apr 16 18:34:09 nobody-t14 kernel: sd 0:0:0:0: [sda] Write Protect is off Apr 16 18:34:09 nobody-t14 kernel: sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00 Apr 16 18:34:09 nobody-t14 kernel: sd 0:0:0:0: [sda] No Caching mode page found Apr 16 18:34:09 nobody-t14 kernel: sd 0:0:0:0: [sda] Assuming drive cache: write through Apr 16 18:34:09 nobody-t14 kernel: sda: Apr 16 18:34:09 nobody-t14 kernel: sd 0:0:0:0: [sda] Attached SCSI removable disk Contemplating getting a second used one for like $20-$30 for investigative purposes, hoping I'd be able to bring this one back. I'd be able to (hopefully) get the stock firmware at least. The other option would be getting a replacement lpc11 online and replacing the one that's on here with that. |
|
Try copying the firmware via Windows. I had issues with copying via Linux. |
|
Thank you for the suggestion! I tested uploading my test qmk firmware and an mbed blinky firmware from a windows 10 machine and they unfortunately gave the same result, including when pulling PIO0_1 high :( |
good luck finding one during this shortage, the one used on the k320 (LQFP48/32kb flash) is expected in stock in February 2023; getting another razer would be a better idea as you said you could try brining it back to life and have something to experiment on.
pulling PIO0_1 manually high shouldn't be needed as most likely its already pulled high for normal operation. Nothing in the user manual (UM10462) suggest the possibility to sign the code, and only allow a specific code to run. Are you doing any changes to the complied binaries? There are two branches where the ISP bootloader is called, either if PIO0_1 is LOW and PIO0_3 is HIGH or if PIO0_3 is HIGH but the user code doesn't pass the validation (20.10 Boot process flowchart in UM10462). There is a note in the same doc, saying that this is something that needs to be done manually if using the ISP bootloader but I never had to do that for QMK firmware or for the blinky program compile with the mbed online compiler. |
I can't find anything in your log, but AN11305 mentions this regarding writing the binary:
|
|
This looks much like the dreadful dd if=<firmware>.bin of=/mnt/FLASH.BIN bs=512 conv=notrunc oflag=direct,syncYou can try this command (adjusting the file names as required). |
I did find a few on aliexpress ( and I would be willing to risk getting a fake) but I bought a second one on eBay instead.
Good to know, thank you.
I have not done any changes to the binaries, though I'm wondering if I'm compiling these incorrectly. Could you send me a firmware that you know works on yours? |
Thank you for the suggestion. Unfortunately that didn't seem to work either. Part of me thinks its just general hardware failure at this point. We'll have to see with the new board. |
here you go, this is currently running on my k320 k320_qmk_firmware.txt (rename to .bin, as github doesn't allow .bin attachments 😄) |
|
Alright this somehow got stranger and more investigation is needed on my part. My board seems to have intermittent issues. Here's an extra reminder to make sure you're touching the right pins when checking for continuity. Twice now I've mixed up PIO0_1 with PIO0_0 (or reset) and Vss, attempting to figure out the proper pinout and what PIO0_1 is used for on this board (I know now it goes to a via on the other side that connects to some of the keys). Thinking I may be pulling PIO0_1 low (and causing it to boot into MSC), I reflowed the solder on the pins on that side of the chip (with PIO0_1). Then after flashing your firmware, it identified itself as a K320! I then also tried the mbed and my qmk firmware, neither of which showed any USB activity but also didn't boot into MSC. While then seeing whether umounting it properly or just unplugging it made my qmk firmware work/not work, it all proceeded to stop working (again), and now only boots to MSC. Actually while typing this managed to flash it again and have it show up as a k320, testing different combinations of unmounting it properly vs just unplugging, different firmwares, Pulling PIO0_1 low only during boot or during the whole process, but sadly it stopped working (again). Still haven't figured out the issue but I think I'm closer. I've been checking if the firmware's being copied correctly by comparing it with What pictures were you interested in? |
|
That is good news that the razer showed as a K320 😄 it means you are on the right track! Indeed strange behavior; what I can tell from experience I never try to probe/touch on the MCU pin, because that always leads to multiple pins touching; instead I see where is the first via/component that is connected to said pin and use that instead. Also my method of triggering the bootloader is to hold PIO0_1 low and trigger a reset via PIO0_0 (after the reset I release PIO0_1), this way I don't have to plug/un-plug the USB cable. Regarding the difference between the compile binary and flash content - AN11305 mentions:
on Windows I don't have this issue, because only copy/delete command are supported and I always need to delete the existing binary and copy a new one. In the AN11305 archive there is a C program, to pad a given binary to have the correct length. I wouldn't worry about the flash dying ... 10.1 Flash memory states min endurance of 10k program/erase cycles with a typical endurance of 100k cycle.
general pictures with the layout of the board and maybe some with the LPC |
|
Good news! After compiling/using padTo.c (that you linked) flashing my razer qmk firmware worked and it showed up correctly! I think doing the reset pin instead of plugging/unplugging the USB also helps. I tried using the Razer firmware updater to see if I could trick it into giving me the stock firmware but alas, it does a version check or something that this firmware doesn't respond to and it fails. Here are some pictures of the board, but unfortunately since it's a 2 layer board that uses vias heavily, and half of the board is covered by a plate, it may not be possible to do keymapping until I remove all the keys (which is what I was going to do anyways since some of them are starting to fail). |
|
I got myself a cheap Corsair K70 to mess around with. It uses the 11U37F and it shows up in Windows. Nothing implemented yet though. The K95 Platinum's 11U68 isn't supported by Chibi yet. |
|
Yeah it's going to take some work. I implemented the 11U1x2x3x for the kemove project specifically. 37 should be compatible with the 35 driver. |
|
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. |
github-actions
bot
added
the
stale
|
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. |
|
This issue is still valid, I've just not had time to come back to it yet haha |
With the work from @dkjer and @tylert durgod k3x0 keyboards with the STM32 hardware are supported by QMK. Unfortunately it appears Durgod has multiple HW revision for the K320 as my keyboard, manufactured circa 2018, has an LPC11U24F MCU.
Feature Request Type
Description
Now I see that ChibiOS has some support for this family of MCUs from NXP, can someone outline what would be the next steps in adding support for this board?
LPC11U35 is supported, LPC11U24 has less flash space and less EEPROM, 32kb/2kb compared to 64kb/4kb on u35; other than that they appear to be identical.
The text was updated successfully, but these errors were encountered: