Uhk60 c2usb integration by benedekkupper · Pull Request #1482 · UltimateHackingKeyboard/firmware

benedekkupper · 2026-02-07T22:42:17Z

major refactoring of UHK60 right USB interface

start using Kconfig for device configuration values (see right/Kconfig.device)
use generated usb_device_config.h header
organize HID report manipulation into self-contained sources and headers
remove kusb interfacing code, except for buspal
update c2usb dependency handling
merge zephyr c2usb interface with UHK60
use single report for system and media usages
remove unused gamepad interface

This PR is work in progress, the following tasks are still ahead:

initial design review of the changes @kareltucek
verification of UHK60 functionality @kareltucek @mondalaci
fix UHK80 build @benedekkupper
fix UHK60 crashes @benedekkupper
investigate and fix UHK80 agent flashing @benedekkupper @kareltucek
create zephyr RTOS design for throttling report sending in usb_report_updater @kareltucek @benedekkupper
merge Kconfigs of UHK60 and UHK80 @benedekkupper
test both UHK60 and UHK80 extensively @benedekkupper @kareltucek @mondalaci

mondalaci · 2026-02-08T08:20:40Z

@benedekkupper Please let me know when I should test a CI build.

kareltucek

As for initial review: looks great. Thanks for all those refactors - they are spot on. I didn't expect you to go this deep into our side of code.

Are there any areas that should I focus on specifically with review?

I mean, are there any notable changes in logic, or potentially controversial areas? (I have tried to read through all the changes, but it is easy to miss things among minor changes, mass renames, etc....)

kareltucek · 2026-02-09T17:14:30Z

right/src/macros/scancode_commands.c


 static void addBasicScancode(uint8_t scancode, macro_usb_keyboard_reports_t* reports)
 {
-    if (!scancode) {


I am wondering if it is safe to remove these...

It is safe to remove them, because the call chain checks for zero values too. It does mean that zero values are processed longer, so if you want to speed up the error handling, I can restore these checks.

kareltucek · 2026-02-09T17:32:17Z

right/src/event_scheduler.h

       EventVector_KeyboardLedState =                      1 << 10,
       EventVector_UsbMacroCommandWaitingForExecution =    1 << 11,
-       EventVector_ProtocolChanged =                       1 << 12,
+       // EventVector_ProtocolChanged =                       1 << 12, // unused


Where is the protocol change (nkro vs 6kro) now handled?

Although, I think it is correct that the usb_report_udpater logic shouldn't be needed these days, as everything is stored in nkro format, so indeed this should be a no issue.

Now the UHK60 handles this internally, just like the UHK80 already does.

kareltucek · 2026-02-10T11:02:52Z

create zephyr RTOS design for throttling report sending in usb_report_updater

What exactly do you have in mind?

What comes to mind given this prompt:

It is fine if the send function blocks for the next couple transport windows. Considering hogp, this means it is fine if you block the main thread for 20ms or so. If you need longer, an error should be returned to trigger resending.
If you give us a function which tells us whether c2usb is readyForNextReport, we can use it and wait with report calculation. With current implementation, this would mean that we poll you once every millisecond. As for alternatives:
- If you also tell us for how long to sleep, we can use that information in sleep calculation.
- Proper solution would be to wait via a semaphore until we receive a callback, but I don't think this is worth the code complexity.
- (The simplest polling solution is preferred.)

Whether and how the reports should be queued - I assume a queue of length 1 - the switching of active and "inactive" report buffers:

In case of usb transport, I think it makes sense for one report to be waiting in the usb stack for transport while another is already being constructed. I.e., "ready" function should return true once there is a free spot in the queue.
In hogp case, due to high latency, optimal would be to calculate the time when a report should be constructed with respect to the next transport window. The simple version would be to calculate next report once the previous report has been sent. In any case, this can be encapsulated in the suggested "readyForNextReport" function.

Assume it takes 1ms to construct a report. (Well, I should make some statistics of this.)

kareltucek · 2026-02-10T12:20:19Z

verification of UHK60 functionality @kareltucek @mondalaci

UHK60 crashes somewhere in initUsb.

What is the state of testing on your end @benedekkupper . Can you efficiently test and debug with actual UHK60 hardware, or is that up to me?

kareltucek · 2026-02-10T12:40:13Z

I have pushed a minor PID fix of west_agent.py.

kareltucek · 2026-02-10T17:45:55Z

device/src/usb/app_base.cpp

-        //return;
-    }
-    std::copy(buffer.begin(), buffer.end(), in_buffer_.data() + sizeof(in_id_));
-    auto result = send_report(in_buffer_);


Have you been dropping all errors here all along?

benedekkupper · 2026-02-14T21:17:41Z

Are there any areas that should I focus on specifically with review?

I mean, are there any notable changes in logic, or potentially controversial areas? (I have tried to read through all the changes, but it is easy to miss things among minor changes, mass renames, etc....)

The key areas are the usb_report_updater.c (as always) and hid/transport.cpp, I'm not entirely confident about the changes affecting the keyboard LED states, and the UsbReportUpdateSemaphore, so please take a closer look at those.

create zephyr RTOS design for throttling report sending in usb_report_updater

What exactly do you have in mind?

What comes to mind given this prompt:

* It is fine if the send function blocks for the next couple transport windows. Considering hogp, this means it is fine if you block the main thread for 20ms or so. If you need longer, an error should be returned to trigger resending.

* If you give us a function which tells us whether c2usb is `readyForNextReport`, we can use it and wait with report calculation. With current implementation, this would mean that we poll you once every millisecond. As for alternatives:
  
  * If you also tell us for how long to sleep, we can use that information in sleep calculation.
  * Proper solution would be to wait via a semaphore until we receive a callback, but I don't think this is worth the code complexity.
  * (The simplest polling solution is preferred.)

Now it will return -EBUSY when the previous report wasn't sent out yet. Hid_KeyboardReportSentCallback and co. with HID_TRANSPORT_BLE will be called when the report was sent (that's your readyForNextReport), so you can pick up from there.

Whether and how the reports should be queued - I assume a queue of length 1 - the switching of active and "inactive" report buffers:
* In case of usb transport, I think it makes sense for one report to be waiting in the usb stack for transport while another is already being constructed. I.e., "ready" function should return true once there is a free spot in the queue.

This is doable, but it needs to split handling USB and BLE report sending, so I'd do it in another round.

* In hogp case, due to high latency, optimal would be to calculate the time when a report should be constructed with respect to the next transport window. The simple version would be to calculate next report once the previous report has been sent. In any case, this can be encapsulated in the suggested "readyForNextReport" function.

Assume it takes 1ms to construct a report. (Well, I should make some statistics of this.)

Don't design too much around this high latency, there is a new BLE spec version already supported by nRF Connect SDK, that can drastically reduce this (LE Shorter Connection Intervals)

UHK60 crashes somewhere in initUsb.

What is the state of testing on your end @benedekkupper . Can you efficiently test and debug with actual UHK60 hardware, or is that up to me?

I have debugged the firmware a bit, but not in a production environment, I flashed the firmware without bootloader present. The keys and mouse movement is working in general, I didn't test further so far due to the limited time availability. Do you have a JTAG/SWD debugger attached, or you use some kind of log and trace functionality? Did yo flash the CI build that crashed, or your local build? Make sure you run the usual west command sequence before build: west config manifest.file west_mcuxsdk.yml && west update && west patch

kareltucek · 2026-02-14T22:45:32Z

Do you have a JTAG/SWD debugger attached, or you use some kind of log and trace functionality?

I tried to attach to a gdb via an swd, but failed. Can look into it deeper on monday I think.

It was a local build.

kareltucek · 2026-02-17T15:29:08Z

As for those crashes:

when deploying from vscode without bootloader, everything works fine for both release and debug builds.
when I flash the regular way - via bootloader and connect to vscode gdb and let the code continue, I get a crash (again with both (export) DEBUG=0 and DEBUG=1 firmwares):

bt
#0  HardFault_Handler () at /opt/west2/firmware/right/src/trace_reasons.c:123
#1  <signal handler called>
#2  0x00034452 in usb::df::function::deinit(usb::df::config::interface const&) ()
#3  0x000323e8 in usb::df::device::set_config(usb::df::config::view, usb::df::device::event) ()
#4  0x2000ee40 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

info registers
r0             0x880bd301          2282476289
r1             0x780               1920
r2             0x787               1927
r3             0x880bd301          2282476289
r4             0x15881             88193
r5             0x1                 1
r6             0x0                 0
r7             0x2000ee00          536931840
r8             0x0                 0
r9             0x1fff1c60          536812640
r10            0x1                 1
r11            0x0                 0
r12            0x0                 0
sp             0x2000ede0          0x2000ede0
lr             0xfffffff1          -15
pc             0x2b7d8             0x2b7d8 <HardFault_Handler>
xpsr           0x10f0003           17760259
fpscr          0x60000010          1610612752
msp            0x2000ede0          0x2000ede0
psp            0x0                 0x0
primask        0x0                 0
basepri        0x0                 0
faultmask      0x0                 0
control        0x0                 0
apsr           0xf0000             983040
epsr           0x1000000           16777216
ipsr           0x3                 3
iapsr          0xf0003             983043
eapsr          0x10f0000           17760256
iepsr          0x1000003           16777219

x/x 0xE000ED28
0xe000ed28:	0x00008200
x/x 0xE000ED2C
0xe000ed2c:	0x40000000
x/x 0xE000ED34
0xe000ed34:	0x880bd301
x/x 0xE000ED38
0xe000ed38:	0x880bd301

kareltucek · 2026-02-17T17:43:29Z

create zephyr RTOS design for throttling report sending in usb_report_updater

Is there any specific concern regarding this? It seems to me that the UsbReportUpdateSemaphore takes care of things quite optimally for now, and so can be checked off.

I went through the usb_report_updater and hid/transport.cpp, and I don't see any obvious issues.

I am running this firmware on uhk80 and it works like a charm so far.

right/src/hid/transport_ble.cpp

kareltucek · 2026-02-18T11:05:33Z

I have lost the ability to flash uhk80 via Agent with this PR.

benedekkupper · 2026-02-21T10:03:08Z

I have lost the ability to flash uhk80 via Agent with this PR.

What error message are you getting?

kareltucek · 2026-02-21T10:12:19Z

It wasn't able to find the bootloader.

kareltucek · 2026-02-21T10:13:23Z

(I mean the Agent.)

benedekkupper · 2026-02-21T10:23:05Z

Is the USB HID index of the agent command interface still hardcoded in the agent?

kareltucek · 2026-02-21T10:28:13Z

No iirc, but I have no hard data for it.

benedekkupper · 2026-02-21T14:20:18Z

@kareltucek I can reproduce the crash, but I'm unable to debug it, as the crash only happens when the bootloader starts the application, and not the debugger. Can you provide some further information about the crash site? Maybe a wireshark capture of the USB communication up to the point of the crash?

kareltucek · 2026-02-21T14:44:41Z

Probably not today I am afraid.

So the problem is that you don't know how to reproduce it with a debugger attached, am I correct?

I used the agent flashing procedure with a local build. These commands in my case:

export DEBUG=1
./build.sh switchMcux
./build.sh right build flashUsb

Which translates to:

west build --build-dir "$BUILD_DIR" "$DEVICE_DIR" --pristine -- --preset "$VARIANT"
west agent --build-dir $BUILD_DIR

I used this launch.json:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "J-Link Debug",
            "type": "cortex-debug",
            "request": "launch",
            "serverpath": "/opt/SEGGER/JLink/JLinkGDBServer",
            "servertype": "jlink",
            "device": "MK22FN512VLH12",
            "interface": "swd",
            "executable": "${workspaceFolder}/right/build/v2-debug/uhk-60-right.elf",
            "loadFiles": ["${workspaceFolder}/right/build/v2-debug/uhk-60-right.elf"],
            "gdbPath": "/opt/arm-gnu-toolchain-15.2.rel1-x86_64-arm-none-eabi/bin/arm-none-eabi-gdb",
            "svdFile": "",
            "runToEntryPoint": "main",
            "overrideLaunchCommands": [
                "monitor halt",
                "monitor reset",
                "load",
                "set $sp = *(0xC000)",
                "set $pc = *(0xC004)"
            ],
            "overrideRestartCommands": [
                "monitor halt",
                "monitor reset",
                "load",
                "set $sp = *(0xC000)",
                "set $pc = *(0xC004)"
            ]
        }
    ]
}

I don't remember the exact procedure though. But should be straightforward.

benedekkupper · 2026-02-23T22:07:32Z

@kareltucek How is the suspend and resume supposed to be signalled to the firmware? I'm calling PowerMode_SetUsbAwake, but this looks like a dummy endpoint.

kareltucek · 2026-02-24T08:06:31Z

It is the correct way. Or the intended way anyways. I just might have disabled it due to past issues with suspend detection 🤔. Also, for uhk80, we need to be awake when any host is active, which makes that api a bit inconvenient as the information source.

What is the intended transport behavior during suspends? I mean, there is that signaling of set connection state. I would expect transport to not be available during suspend, but I am not sure about the semantics.

zephyrproject-rtos/zephyr#96609

…velopment

* start using Kconfig for device configuration values (see right/Kconfig.device) * use generated usb_device_config.h header * organize HID report manipulation into self-contained sources and headers * remove kusb interfacing code, except for buspal * update c2usb dependency handling * merge zephyr c2usb interface with UHK60 * use single report for system and media usages * remove unused gamepad interface

benedekkupper · 2026-02-24T20:19:37Z

It is the correct way. Or the intended way anyways. I just might have disabled it due to past issues with suspend detection 🤔. Also, for uhk80, we need to be awake when any host is active, which makes that api a bit inconvenient as the information source.

I had to use different calls to make it work as before, something to solve at some point.

What is the intended transport behavior during suspends? I mean, there is that signaling of set connection state. I would expect transport to not be available during suspend, but I am not sure about the semantics.

The transport isn't available for sending during suspend. Preparing to receive is still allowed, but nothing will be delivered until the bus is resumed.

benedekkupper · 2026-02-24T21:27:45Z

The crashes are fixed, please retest @kareltucek

benedekkupper requested a review from kareltucek February 7, 2026 22:42

cla-sign-bot bot added the cla:signed label Feb 7, 2026

benedekkupper force-pushed the uhk60-c2usb-integration branch 5 times, most recently from c094435 to f2f5ac6 Compare February 8, 2026 22:12

kareltucek reviewed Feb 10, 2026

View reviewed changes

kareltucek reviewed Feb 17, 2026

View reviewed changes

right/src/hid/transport_ble.cpp Show resolved Hide resolved

kareltucek mentioned this pull request Feb 19, 2026

UHK80 connected via USB sometimes seems not to send keypress information after being idle #1407

Open

benedekkupper force-pushed the uhk60-c2usb-integration branch from 5e777d3 to e61c346 Compare February 21, 2026 09:16

benedekkupper marked this pull request as ready for review February 21, 2026 10:00

benedekkupper force-pushed the uhk60-c2usb-integration branch 2 times, most recently from 037c4a4 to a074135 Compare February 21, 2026 10:12

benedekkupper force-pushed the uhk60-c2usb-integration branch from 662caed to 9d69bfa Compare February 23, 2026 21:41

benedekkupper and others added 22 commits February 24, 2026 21:17

nrf: update sysbuild presets workaround with upstream

4cce035

zephyrproject-rtos/zephyr#96609

move c2usb interfacing code under the right sources

3ddc00f

split vscode to two workspaces, one for nrfsdk and one for mcuxsdk de…

3024788

…velopment

right: integrate c2usb into the build, without any effect

5f81d5a

tooling configuration update

fbe3b65

Fix PID in west_agent.py

5b96ac5

Handle uhk60 debug builds in build.sh.

486456d

Add vscode build variants.

fe7572b

Log and reconnect on repeated report send fails.

8bb8b9a

Check hogp health. Disconnect if it doesn't look good.

e8fbbf0

release with debug info

fd50e7a

scripts: add west vscode command

2bffb67

Fix healthcheck compilation.

19af1a9

Use system build environment in build.sh.

716f69f

DOCS: add uhk80 vscode debugging stuff.

65a451b

agent doesn't support report ID on UHK60

e88d13e

uhk60: make debugging possible with bootloader+app flashing

3f48a9c

c2usb fixes

ae64685

ci: use latest zephyr SDK

dd4bde1

uhk60: restore suspend and resume handling

15ddd86

assume high resolution scrolling when enumerated on Windows

ec56ae9

benedekkupper force-pushed the uhk60-c2usb-integration branch from 2dcb42e to ec56ae9 Compare February 24, 2026 20:17

uhk60: fix buspal USB

bc2c975

Conversation

benedekkupper commented Feb 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mondalaci commented Feb 8, 2026

Uh oh!

kareltucek left a comment

Choose a reason for hiding this comment

Uh oh!

kareltucek Feb 9, 2026

Choose a reason for hiding this comment

Uh oh!

benedekkupper Feb 14, 2026

Choose a reason for hiding this comment

Uh oh!

kareltucek Feb 9, 2026

Choose a reason for hiding this comment

Uh oh!

kareltucek Feb 10, 2026

Choose a reason for hiding this comment

Uh oh!

benedekkupper Feb 14, 2026

Choose a reason for hiding this comment

Uh oh!

kareltucek commented Feb 10, 2026

Uh oh!

kareltucek commented Feb 10, 2026

Uh oh!

kareltucek commented Feb 10, 2026

Uh oh!

kareltucek Feb 10, 2026

Choose a reason for hiding this comment

Uh oh!

benedekkupper commented Feb 14, 2026

Uh oh!

kareltucek commented Feb 14, 2026

Uh oh!

kareltucek commented Feb 17, 2026

Uh oh!

kareltucek commented Feb 17, 2026

Uh oh!

Uh oh!

kareltucek commented Feb 18, 2026

Uh oh!

benedekkupper commented Feb 21, 2026

Uh oh!

kareltucek commented Feb 21, 2026

Uh oh!

kareltucek commented Feb 21, 2026

Uh oh!

benedekkupper commented Feb 21, 2026

Uh oh!

kareltucek commented Feb 21, 2026

Uh oh!

benedekkupper commented Feb 21, 2026

Uh oh!

kareltucek commented Feb 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

benedekkupper commented Feb 23, 2026

Uh oh!

kareltucek commented Feb 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

benedekkupper commented Feb 24, 2026

Uh oh!

benedekkupper commented Feb 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

benedekkupper commented Feb 7, 2026 •

edited

Loading

kareltucek commented Feb 21, 2026 •

edited

Loading

kareltucek commented Feb 24, 2026 •

edited

Loading