Locked Status with Multiple Shared Resources

[adrianncovaci]

I am developing a project using RTIC on an STM32 platform and I've encountered an issue where the addition of multiple shared resources causes the system to enter a locked state. Initially, I suspected a stack overflow problem, as the lockup occurred following the addition of new data to the stack. However, after inspecting the sp register, it appears that the register is still well within the bounds of the RAM memory.

I've prepared a minimal reproducible example that demonstrates the issue.
GitHub - wingman-repro

When running the example, after adding a specific number of shared resources, the system does not respond as expected and seems to be in a locked state; the system simply stops responding.

Disabling the additional shared resources one by one or building with the release flag via
cargo build --release --features defmt --config .cargo/config_defmt.toml --package wingman_io2_foiler appears to mitigate the issue.

I've also tried compiling with both stable and nightly channels.

Could you please help me understand what might be causing this issue? Additionally, if there are any specific debugging techniques or tool configurations that could help mitigate the problem, that would be very helpful.

Additional info:
RTIC Version: 2
Target Platform: STM32H747
Rust Version: rustc 1.79.0

Thank you for your work on developing this project!

[perlindgren]

Its hard to tell what the problem might be as the example is quite large. Could you try replicating the problem in isolation. Perhaps just by a simple crate with just a lot of RTIC resources and very simple "business" logic.

Is there an error reported, and if so from where?