[Bug] keyboards/kinesis/kint41 hangs for 10 seconds or indefinitely

[stevenbetten]

Describe the Bug

Since commit 416af01, keyboards/kinesis/kint41 hangs for 10 seconds or indefinitely. I experienced an indefinite hang on my kint41 keyboard after flashing the result of make kinesis/kint41:default built from the head of qmk_firmware. In contrast, the keyboard works well when flashed from qmk_firmware tag 0.21.6. I found kinx-project/kint#77, which describes other users experiencing the issue.

Keyboard Used

kinesis/kint41

Link to product page (if applicable)

No response

Operating System

macOS 13.6.3 (22G436)

qmk doctor Output

steve@Stevens-MacBook-Pro qmk_firmware % qmk doctor
Ψ QMK Doctor is checking your environment.
Ψ CLI version: 1.1.2
Ψ QMK home: /Users/steve/qmk_firmware
Ψ Detected macOS 13.6.3 (Apple Silicon).
Ψ Userspace enabled: False
Ψ Git branch: master
Ψ Repo version: 0.23.9
Ψ - Latest master: 2024-02-06 18:09:22 +1100 (45ae4dec4d) -- WS2812: Better error message when trying to use `bitbang` driver on RP2040 (#23025)
Ψ - Latest upstream/master: 2024-02-06 18:09:22 +1100 (45ae4dec4d) -- WS2812: Better error message when trying to use `bitbang` driver on RP2040 (#23025)
Ψ - Latest upstream/develop: None
Ψ - Common ancestor with upstream/master: 2024-02-06 18:09:22 +1100 (45ae4dec4d) -- WS2812: Better error message when trying to use `bitbang` driver on RP2040 (#23025)
Ψ - Common ancestor with upstream/develop: None
Ψ CLI installed in virtualenv.
Ψ All dependencies are installed.
Ψ Found arm-none-eabi-gcc version 8.5.0
Ψ Found avr-gcc version 8.5.0
Ψ Found avrdude version 7.2
Ψ Found dfu-programmer version 1.1.0
Ψ Found dfu-util version 0.11
Ψ Submodules are up to date.
Ψ Submodule status:
Ψ - lib/chibios: 2023-04-15 13:48:04 +0000 --  (11edb1610)
Ψ - lib/chibios-contrib: 2023-07-17 11:39:05 +0200 --  (da78eb37)
Ψ - lib/googletest: 2021-06-11 06:37:43 -0700 --  (e2239ee6)
Ψ - lib/lufa: 2022-08-26 12:09:55 +1000 --  (549b97320)
Ψ - lib/vusb: 2022-06-13 09:18:17 +1000 --  (819dbc1)
Ψ - lib/printf: 2022-06-29 23:59:58 +0300 --  (c2e3b4e)
Ψ - lib/pico-sdk: 2023-02-12 20:19:37 +0100 --  (a3398d8)
Ψ - lib/lvgl: 2022-04-11 04:44:53 -0600 --  (e19410f8)
Ψ QMK is ready to go

Is AutoHotKey / Karabiner installed

• AutoHotKey (Windows)
• Karabiner (macOS)

Other keyboard-related software installed

No response

Additional Context

No response

[stevenbetten]

fauxpark closed the corresponding pull request a few hours ago as "This doesn't do anything." but I asked them to explain why they think that, because I disagree. See #23054.

[tzarc]

Replicating my comment from the now-closed PR:

---

For clarity, the ChibiOS code for MIMXRT1062 was apparently written purely for the kint41. It seems to be a bare-bones and potentially broken implementation -- it's been reported that anything to do with timing in QMK is flat-out broken on MIMXRT1062-based boards.

I've attached two files -- disassembly from before and after applying the PR. Apart from the WFI call, there seems to be a missing port_unlock()? Perhaps there's an issue with preprocessor in the underlying ChibiOS port, mistakenly removing the wrong function call?

kinesis_kint41_default.elf.base.dis.txt
kinesis_kint41_default.elf.pr.dis.txt

I'd say the general issue here is that the usual interrupts aren't firing, and ChibiOS isn't scheduling the QMK main thread for execution as a result. Interrupts such as USB or SysTick tend to keep QMK running, and perhaps these aren't enabled in the MIMXRT1062 port.

Also something to at least try -- ChibiOS creates an idle thread even though QMK should be running as a hard loop -- you could try adding -DCH_CFG_NO_IDLE_THREAD=TRUE to instruct ChibiOS not to create the idle thread. This isn't likely going to be accepted as a fix; it's more we don't have any MIMXRT1062 boards that we can test with -- adding the define will tell us more about the correct course of action.

[stevenbetten]

Nick, thanks for the additional comments!-SteveOn Feb 14, 2024, at 06:25, Nick Brassel ***@***.***> wrote: Replicating my comment from the now-closed PR: For clarity, the ChibiOS code for MIMXRT1062 was apparently written purely for the kint41. It seems to be a bare-bones and potentially broken implementation -- it's been reported that anything to do with timing in QMK is flat-out broken on MIMXRT1062-based boards. I've attached two files -- disassembly from before and after applying the PR. Apart from the WFI call, there seems to be a missing port_unlock()? Perhaps there's an issue with preprocessor in the underlying ChibiOS port, mistakenly removing the wrong function call? kinesis_kint41_default.elf.base.dis.txt kinesis_kint41_default.elf.pr.dis.txt I'd say the general issue here is that the usual interrupts aren't firing, and ChibiOS isn't scheduling the QMK main thread for execution as a result. Interrupts such as USB or SysTick tend to keep QMK running, and perhaps these aren't enabled in the MIMXRT1062 port. Also something to at least try -- ChibiOS creates an idle thread even though QMK should be running as a hard loop -- you could try adding -DCH_CFG_NO_IDLE_THREAD=TRUE to instruct ChibiOS not to create the idle thread. This isn't likely going to be accepted as a fix; it's more we don't have any MIMXRT1062 boards that we can test with -- adding the define will tell us more about the correct course of action. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>