Open bofh69 opened 2 years ago
Digging more I found this:
The TRANSACTION_HANDLER_MASTER/TRANSACTION_HANDLER_SLAVE macros uses ATOMIC_BLOCK_FORCEON when calling their handler functions. ATOMIC_BLOCK_FORCEON uses chSysLock() to implement the locking, thus leading to the second locking in the usart_clear code.
Just removing osalSysLock() from usart_clear() and adding it around the calls to usart_clear() in SlaveThread isn't enough though to fix the original problem. The code hangs somewhere else instead.
I think this needs to be investigated on a devboard with a debug probe so one can get proper stack traces.
The proper solution is probably to use reentrant locks instead. People always make these misstakes with non-reentrant locks. That is probably a harder fix though.
Describe the Bug
With CH_DBG_SYSTEM_STATE_CHECK defined as TRUE, SPLIT_KEYBOARD doesn't work with Teensy LC with a setup derived from the handwired/onekey/teensy_lc example.
The system seems to work fine fine if I turn off CH_DBG_SYSTEM_STATE_CHECK
I can see in dmesg on my ubuntu box that the usb device is detected, but five seconds later it says "can't add hid device: -32" and it doesn't work.
It seems osalSysLock is somehow called twice before the unlock call is called.
I've copied handwired/onekey/teensy_lc and turned it into a split keyboard setup with two rows, one column. (One row per keyboard half).
I've added:
to my keyboard.c file.
By toggling the LED I've managed to track down the hang to when usart_clear is called, it never gets past the osalSysLock call (if I follow all the calls correctly, it is the _dbg_check_lock(); that doesn't return). If I turn off CH_DBG_SYSTEM_STATE_CHECK, then it seems to work, I can at least input both of my keys.
I've also seen that the Hardfault-, MemFault- or BusFault_-Handlers are not called.
My config.h contains:
rules.mk:
hal_config.h:
mcu_conf.h:
chconf.h is identical to handwired/onekey/teensy_lc's.
the other rules.mk file is:
I've also created a new ortho_1x2 layout with two rows, one column.
I've decreased the stack use by some threads (the same error happens with smaller USB/SERIAL buffers and the original sizes of the stacks too): THD_WORKING_AREA(waSlaveThread, 512); THD_WORKING_AREA(serialThreadStack, 512); USE_PROCESS_STACKSIZE = 0x700
System Information
Additional Context