zmkfirmware / zmk

ZMK Firmware Repository
https://zmk.dev/
MIT License
2.59k stars 2.66k forks source link

Macros freeze/hangs keyboard on stm32 #2375

Open macseem opened 1 month ago

macseem commented 1 month ago

Pressing key assigned to a macros doesn't do anything After that keyboard stops responding Macros complexity doesn't matter, default one from documentation behaves the same Key position/layer anything else doesn't change situation.

This is reproducing using on both github actions build and local west build Both builds are successful and don't fail

Any other behaviour works as expected (hold-tap, mod-tap, etc),

Board: STM32 f411ce black pill

Keymap configuration:

#include <behaviors.dtsi>
#include <dt-bindings/zmk/keys.h>

/{
    macros {
        zed_em_kay: zed_em_kay {
            compatible = "zmk,behavior-macro";
            #binding-cells = <0>;
            bindings
                = <&macro_press &kp LSHFT>
                , <&macro_tap &kp Z &kp M &kp K>
                , <&macro_release &kp LSHFT>
                ;
        };
    };
    keymap {
        compatible = "zmk,keymap";
        default_layer {
            bindings = <
&zed_em_kay &none &none &none
&none       &none &none &none
&none       &none &none &none
            >;
            label = "Default layer";
        };
    };
};

Here is overlay

/ {
    chosen {
      zmk,kscan = &default_kscan;
    };

    default_kscan: kscan {
      compatible = "zmk,kscan-gpio-matrix";
      label = "default_kscan";
      diode-direction = "col2row";

      col-gpios
        = <&blackpill 14 GPIO_ACTIVE_HIGH>
        , <&blackpill 15 GPIO_ACTIVE_HIGH>
        , <&blackpill 16 GPIO_ACTIVE_HIGH>
        , <&blackpill 17 GPIO_ACTIVE_HIGH>
        ;

      row-gpios 
        = <&blackpill 18 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)>
        , <&blackpill 19 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)>
        , <&blackpill 20 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)>
        ;

    };
};
caksoylar commented 1 month ago

Can you also get logging output? https://zmk.dev/docs/development/usb-logging

macseem commented 1 month ago

@caksoylar I tried to add logging, but it fails to compile, whenever I set flag on it just pops with lots of errors like here https://github.com/macseem/zmk-config/actions/runs/9110620165

petejohanson commented 1 month ago

@caksoylar I tried to add logging, but it fails to compile, whenever I set flag on it just pops with lots of errors like here https://github.com/macseem/zmk-config/actions/runs/9110620165

See the updates docs on using the new logging snippet to enable this: https://zmk.dev/docs/development/usb-logging#usb-logging-snippet

I would guess that you're blowing the stack, but hard to tell for sure. You could try bumping the system work queue stack size too.

macseem commented 1 month ago

Oh, haven't seen updated docs for usb logging, thanks for pointing, will try. it defo feels like stack overflow or something similar. will try new logging and return with logs.

You could try bumping the system work queue stack size too.

Not sure how to do this one, I don't have much experience with zephyr

petejohanson commented 1 month ago

Oh, haven't seen updated docs for usb logging, thanks for pointing, will try. it defo feels like stack overflow or something similar. will try new logging and return with logs.

You could try bumping the system work queue stack size too.

Not sure how to do this one, I don't have much experience with zephyr

You can set:

CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048

For instance. If building locally, you can do a west build -d build/some_build_dir -t menuconfig to change it locally too (just don't build with -p/--pristine after or it will blow away config changes).

lesshonor commented 1 month ago

I can confirm that bumping the system workqueue size to 2048 allows that macro to function without locking up the board, at least for this shield.

If you manage to get USB logging functional on a BlackPill, I would love to see your configuration. I have never managed to get more than a couple of lines from it before a disconnect + USB enumeration failure, and have yet to dig deeply enough to figure out any idea why. (While the STM32F4x1 is regrettably short on bidirectional USB endpoints, I think four should be enough here...) BlackPill logging (USB CDC ACM generally) is broken due to a bug introduced in https://github.com/zmkfirmware/zephyr/commit/304b57b530a3880313549c2ea81d8cefea0450c3. Issue https://github.com/zephyrproject-rtos/zephyr/issues/69657 was filed about it, and the problem was eventually fixed in https://github.com/zephyrproject-rtos/zephyr/pull/70795.

To restore USB logging, you can:

For the record: this also affects mouse emulation.