I am running standard FreeRTOS on Pico.
The firmware I am writing receives strings on UART to run functions, aka Remote Procedure Calls.
I use the SDK's stdio_uart, so on init.
That callback saves incoming characters to a ring buffer, and upon \n, notifies a FreeRTOS task with `xTaskNotifyFromISR(...)`. It is my understanding that the task receiving the notification does _not_ run in ISR context.
From there, the receiving task parses the string, and calls functions accordingly.
During development, I add printfs at crucial places to make sure that the data looks the way I expect (I sure do use gdb as well, but printfs are sometimes more practical).
My issue: without the printfs, the code does what it should. But with the printfs, especially in combination with %d, I get a hardfault.
Here is the backtrace:Protecting the printf with save/disable/restore interrupts seemed to help for a while, but not always.
Without the printfs, nothing comes out of the UART at all, so I do not suspect collisions with other calls to printf.
What is going wrong? Why to I get hardfaults upon using printf with variable parameters?
The firmware I am writing receives strings on UART to run functions, aka Remote Procedure Calls.
I use the SDK's stdio_uart, so
Code:
stdio_set_chars_available_callback(rpc_on_char_input, NULL);That callback saves incoming characters to a ring buffer, and upon \n, notifies a FreeRTOS task with `xTaskNotifyFromISR(...)`. It is my understanding that the task receiving the notification does _not_ run in ISR context.
From there, the receiving task parses the string, and calls functions accordingly.
During development, I add printfs at crucial places to make sure that the data looks the way I expect (I sure do use gdb as well, but printfs are sometimes more practical).
My issue: without the printfs, the code does what it should. But with the printfs, especially in combination with %d, I get a hardfault.
Here is the backtrace:
Code:
Thread 1 "rp2040.core0" received signal SIGTRAP, Trace/breakpoint trap.isr_hardfault () at /home/gostervall/src/rewinder-fw/vendor/pico-sdk/src/rp2_common/pico_standard_link/crt0.S:9898decl_isr_bkpt isr_hardfault(gdb) bt#0 isr_hardfault () at /home/gostervall/src/rewinder-fw/vendor/pico-sdk/src/rp2_common/pico_standard_link/crt0.S:98#1 <signal handler called>#2 uart_is_writable (uart=0x1) at /home/gostervall/src/rewinder-fw/vendor/pico-sdk/src/rp2_common/hardware_uart/include/hardware/uart.h:286#3 0x10007594 in uart_write_blocking (uart=0x1, src=0x20001413 "0\001", len=1) at /home/gostervall/src/rewinder-fw/vendor/pico-sdk/src/rp2_common/hardware_uart/include/hardware/uart.h:321#4 0x10007642 in uart_putc_raw (uart=0x1, c=48 '0') at /home/gostervall/src/rewinder-fw/vendor/pico-sdk/src/rp2_common/hardware_uart/include/hardware/uart.h:356#5 0x1000768c in uart_putc (uart=0x1, c=48 '0') at /home/gostervall/src/rewinder-fw/vendor/pico-sdk/src/rp2_common/hardware_uart/include/hardware/uart.h:373#6 0x1000777e in stdio_uart_out_chars (buf=0x20001498 "900\n", length=4) at /home/gostervall/src/rewinder-fw/vendor/pico-sdk/src/rp2_common/pico_stdio_uart/stdio_uart.c:86#7 0x10006eee in stdio_out_chars_crlf (driver=0x200004b0 <stdio_uart>, s=0x20001498 "900\n", len=4) at /home/gostervall/src/rewinder-fw/vendor/pico-sdk/src/rp2_common/pico_stdio/stdio.c:67#8 0x1000724a in stdio_stack_buffer_flush (buffer=0x20001494) at /home/gostervall/src/rewinder-fw/vendor/pico-sdk/src/rp2_common/pico_stdio/stdio.c:233#9 0x100072ee in __wrap_vprintf (format=0x1000db2c "%d\n", va=...) at /home/gostervall/src/rewinder-fw/vendor/pico-sdk/src/rp2_common/pico_stdio/stdio.c:259#10 0x1000732a in __wrap_printf (format=0x1000db2c "%d\n") at /home/gostervall/src/rewinder-fw/vendor/pico-sdk/src/rp2_common/pico_stdio/stdio.c:278Without the printfs, nothing comes out of the UART at all, so I do not suspect collisions with other calls to printf.
What is going wrong? Why to I get hardfaults upon using printf with variable parameters?
Statistics: Posted by gostervall — Wed Feb 07, 2024 2:47 pm