Hello, it's my first time posting on this forum. I'm pretty clever but also prone to stupidly overlooking things.
I've been writing embedded firmware in c for years on various devices, but I'm self-taught so there are various gaps in my knowledge.
For my current project, I'm using an RP2350 to try to make a device that can synchronize a bunch of clock signals for musical purposes, so that an array of several desktop music-making sequencer boxes, drum machines, pattern generators etc. can all lock into the same groove.
This requires a lot of I/O, so I'm using every available GPIO on the 2350 to service up to four UARTs (two onboard plus two PIO-emulated UARTs), two I2C busses (EEPROM and some additional IO expander chips), two SPIs (OLED display and a WiFi submodule), several PWM outputs, etc. etc.
Everything was working fine up to a point, and then I tried to add some more repeating-timer interrupts or alarms to the system, to handle various things like adding delay to certain clock signals so you could adjust their phase relative to others.
All of a sudden, it seems like everything I do (any way I try to add another alarm pool callback, or repeating timer, or similar) triggers an isr_hardfault.
It's probably relevant that I am running code on both (ARM) cores, although it seems like I get a very similar isr_hardfault regardless of which core I try to add a repeating timer or alarm to.
What it looks like is that whenever my newly-added IRQ handler is called (probably added incorrectly in some way that I'd love help with), the system halts and I see some "signal handler called" at some high address, from an "Unknown Source"
example call stack:
isr_hardfault@0x10000114
<signal handler called>@0xfffffff1 (Unknown Source:0)
default_alarm_pool_callback@0x10002880
alarm_pool_irq_handler@0x1000538a
<signal handler called>@0xfffffff9 (Unknown Source:0)
Or, I can get a similar hardfault seemingly when I try to get_absolute_time() on core1 while core0 is doing i2c_read_blocking_internal():
(core0:)
i2c_read_blocking_internal@0x10008f8a (~/.pico-sdk/sdk/2.1.1/src/rp2_common/hardware_i2c/i2c.c:305)
i2c_read_blocking@0x10009128
Mcp23017::read_dual_registers@0x100092fc
Mcp23017::update_and_get_input_values@0x1000935e
main@0x100020ee
(core1:)
isr_hardfault@0x10000114
<signal handler called>@0xfffffff9 (Unknown Source:0)
delayTimer_handler@0x10002764 <-- when it crashed, this function was on the line "if (absolute_time_diff_us(ptr->timestamp, get_absolute_time()) >= 0)"
core1_main@0x100027cc
core1_wrapper@0x1000862e
??@0x00000180 (Unknown Source:0)
So... I am guessing that I must have things interrupting other things in some incorrect way, but I'm really not sure where to look to begin debugging this. Have I provided enough info to suggest an avenue of inquiry?
Thanks to anyone who has any ideas to contribute.
kind regards,
Amos
I've been writing embedded firmware in c for years on various devices, but I'm self-taught so there are various gaps in my knowledge.
For my current project, I'm using an RP2350 to try to make a device that can synchronize a bunch of clock signals for musical purposes, so that an array of several desktop music-making sequencer boxes, drum machines, pattern generators etc. can all lock into the same groove.
This requires a lot of I/O, so I'm using every available GPIO on the 2350 to service up to four UARTs (two onboard plus two PIO-emulated UARTs), two I2C busses (EEPROM and some additional IO expander chips), two SPIs (OLED display and a WiFi submodule), several PWM outputs, etc. etc.
Everything was working fine up to a point, and then I tried to add some more repeating-timer interrupts or alarms to the system, to handle various things like adding delay to certain clock signals so you could adjust their phase relative to others.
All of a sudden, it seems like everything I do (any way I try to add another alarm pool callback, or repeating timer, or similar) triggers an isr_hardfault.
It's probably relevant that I am running code on both (ARM) cores, although it seems like I get a very similar isr_hardfault regardless of which core I try to add a repeating timer or alarm to.
What it looks like is that whenever my newly-added IRQ handler is called (probably added incorrectly in some way that I'd love help with), the system halts and I see some "signal handler called" at some high address, from an "Unknown Source"
example call stack:
isr_hardfault@0x10000114
<signal handler called>@0xfffffff1 (Unknown Source:0)
default_alarm_pool_callback@0x10002880
alarm_pool_irq_handler@0x1000538a
<signal handler called>@0xfffffff9 (Unknown Source:0)
Or, I can get a similar hardfault seemingly when I try to get_absolute_time() on core1 while core0 is doing i2c_read_blocking_internal():
(core0:)
i2c_read_blocking_internal@0x10008f8a (~/.pico-sdk/sdk/2.1.1/src/rp2_common/hardware_i2c/i2c.c:305)
i2c_read_blocking@0x10009128
Mcp23017::read_dual_registers@0x100092fc
Mcp23017::update_and_get_input_values@0x1000935e
main@0x100020ee
(core1:)
isr_hardfault@0x10000114
<signal handler called>@0xfffffff9 (Unknown Source:0)
delayTimer_handler@0x10002764 <-- when it crashed, this function was on the line "if (absolute_time_diff_us(ptr->timestamp, get_absolute_time()) >= 0)"
core1_main@0x100027cc
core1_wrapper@0x1000862e
??@0x00000180 (Unknown Source:0)
So... I am guessing that I must have things interrupting other things in some incorrect way, but I'm really not sure where to look to begin debugging this. Have I provided enough info to suggest an avenue of inquiry?
Thanks to anyone who has any ideas to contribute.
kind regards,
Amos
Statistics: Posted by controlvoltage — Thu Jun 26, 2025 4:35 am