You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
I think the issue was indeed a memory issue after all, after changing the location of the stack to the origin of the axis ram, everything seems to run ok.
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!
The text was updated successfully, but these errors were encountered: