Macros freeze/hangs keyboard on stm32

[macseem]

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]

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

[macseem]

@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]

@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]

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]

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]

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 zmkfirmware/zephyr@304b57b. Issue zephyrproject-rtos/zephyr#69657 was filed about it, and the problem was eventually fixed in zephyrproject-rtos/zephyr#70795.

To restore USB logging, you can:

• either revert zmkfirmware/zephyr@304b57b
• or cherry-pick zephyrproject-rtos/zephyr@c481525 and zephyrproject-rtos/zephyr@e69ce5b

For the record: this also affects mouse emulation.