Open stevenbetten opened 8 months ago
stevenbetten
commented
8 months ago 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 https://github.com/qmk/qmk_firmware/pull/23054.
tzarc
commented
8 months ago 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
commented
8 months ago 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: @.***>
Describe the Bug
Since commit 416af0171c6433a7ecb198386dd2c3ac70d4cbd2, 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:defaultbuilt from the head of qmk_firmware. In contrast, the keyboard works well when flashed from qmk_firmware tag 0.21.6. I found https://github.com/kinx-project/kint/issues/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
Is AutoHotKey / Karabiner installed
Other keyboard-related software installed
No response
Additional Context
No response