Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

async memory usage #75

Closed
davidqge opened this issue Sep 24, 2024 · 5 comments · Fixed by #89
Closed

async memory usage #75

davidqge opened this issue Sep 24, 2024 · 5 comments · Fixed by #89

Comments

@davidqge
Copy link
Contributor

run_rmk cause stack protection fault on esp32c6 with 100kb stack.

This article talks about wrapper async function's memory usage [rebinding values in an async function can double the memory usage
#96084](rust-lang/rust#96084)

0.959410 INFO Advertising..
    Guru Meditation Error: Core  0 panic'ed (Stack protection fault).
    
    Detected in task "main" at 0x4080c1be
    0x4080c1be - xQueueSemaphoreTake
        at /home/embedded/rmk/examples/use_rust/esp32c6_ble/.embuild/espressif/esp-idf/v5.2.2/components/freertos/FreeRTOS-Kernel/queue.c:1699
    Stack pointer: 0x40818f20
    Stack bounds: 0x40818f4c - 0x408317e0
    
    
    Core  0 register dump:
    MEPC    : 0x4080da26  RA      : 0x4080c1d4  SP      : 0x40818f20  GP      : 0x40812040
    0x4080da26 - xTaskGetSchedulerState
        at /home/embedded/rmk/examples/use_rust/esp32c6_ble/.embuild/espressif/esp-idf/v5.2.2/components/freertos/FreeRTOS-Kernel/tasks.c:4972
    0x4080c1d4 - xQueueSemaphoreTake
        at /home/embedded/rmk/examples/use_rust/esp32c6_ble/.embuild/espressif/esp-idf/v5.2.2/components/freertos/FreeRTOS-Kernel/queue.c:1718
    0x40812040 - coex_schm_ble_mesh_standby_bt_a2dp_paused_wifi_connecting
        at ??:??
    TP      : 0x408053b0  T0      : 0x40028140  T1      : 0xffffffe0  T2      : 0xffffffff
    0x408053b0 - r_ble_lll_sched_insertion_begin
        at ??:??
    S0/FP   : 0x408179bc  S1      : 0xffffffff  A0      : 0x408179bc  A1      : 0xffffffff
    A2      : 0x00000004  A3      : 0x00000000  A4      : 0x00000001  A5      : 0x00000001
    A6      : 0x00000000  A7      : 0x00000000  S2      : 0x00000000  S3      : 0xffffffff
    S4      : 0x40831848  S5      : 0x40820768  S6      : 0x40820768  S7      : 0x40823e58
    S8      : 0x40819800  S9      : 0x40820768  S10     : 0x420aceaf  S11     : 0x0000000c
    T3      : 0x00000001  T4      : 0x00000000  T5      : 0x0000003e  T6      : 0x40803e80
    0x40803e80 - npl_freertos_time_delay
        at /home/embedded/rmk/examples/use_rust/esp32c6_ble/.embuild/espressif/esp-idf/v5.2.2/components/bt/porting/npl/freertos/src/npl_os_freertos.c:997
    MSTATUS : 0x00001881  MTVEC   : 0x40800001  MCAUSE  : 0x0000001b  MTVAL   : 0x408167b7
    0x40800001 - _vector_table
        at ??:??
    0x408167b7 - ble_store_config_our_secs
        at ??:??
    MHARTID : 0x00000000
@HaoboGu
Copy link
Owner

HaoboGu commented Sep 25, 2024

The issue says "This seems to only happen if the value was borrowed earlier". I suspect the cause is not the async run_rmk.

@HaoboGu
Copy link
Owner

HaoboGu commented Sep 25, 2024

I did some improvements for run_rmk: #76

@davidqge
Copy link
Contributor Author

Still happens,

I committed the larger kinesis keymap, see if you can reproduce it.

My fix, alias esp function can run within 64kb stack.

@HaoboGu
Copy link
Owner

HaoboGu commented Sep 25, 2024

this is quite strange🤔, I will take a look later

@HaoboGu
Copy link
Owner

HaoboGu commented Sep 26, 2024

I checked stack size using -Zemit-stack-sizes on nrf52840 example, using run_rmk and initialize_nrf_ble_keyboard_with_config_and_run emits same stack size. I suspect it's related only to esp32. (I was not able to get stack size for esp :(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants