This doesn't do anything.

Hi, fauxpark. Can you please elaborate on why you commented (and presumably think) that "This doesn't do anything"? Adding OPT_DEFS += -DCORTEX_ENABLE_WFI_IDLE=FALSE to the rules.mk, as my commit does, definitely does set the value to FALSE, whereas the default for all keyboards is now TRUE. And setting this to FALSE fixes the issue on my and other people's kint41 keyboards as documented in kinx-project/kint#77. Can you please indicate where my analysis is incorrect? Thanks!

Hi, fauxpark, please see 416af01 for the commit that switched all keyboards to OPT_DEFS += -DCORTEX_ENABLE_WFI_IDLE=TRUE, thus breaking kinesis/kint41, whose value was implicitly FALSE before that commit.

Sounds like something is wrong with the MIMXRT1062 code in ChibiOS then.

Teensy 4.x boards are barely supported by QMK as it is.

That's not what I'm saying. This is not a bug in QMK, it is a bug in ChibiOS. You need to take it up there.

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.