Stack size update for STM32F4 boards #2223
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
2 tasks
Contributor
|
Contributor
|
I tried changing memory space allocated to nonvolatile_storage in main.rs, but that didn't solve it. I managed to get it to compile only if i excluded nonvolatile_storage from main.rs. Sadly, the blink app even in that case didn't work. (so it must be something else besides the stack size) |
Contributor
|
It works normally on Nucleo-F429ZI. |
Contributor
|
Thanks for testing and submitting this. I think the issue on stm32f3 is just a flash size issue that is separate from this. I'm going to look into that next week. As an aside, the new peripheral instantiation approach requiring so much stack because it initializes all peripherals at once is a flaw. I'm going to try to rewrite the initialization code so only one peripheral is on the stack at a time, but that will also not be for a few days. |
hudson-ayers
previously approved these changes
Nov 25, 2020
alexandruradovici
changed the title
Contributor
Author
|
Merging this as a quick fix would be helpful as no STM boards work right now. |
Contributor
2 tasks
bors bot
added a commit
that referenced
this pull request
Feb 9, 2021
2400: Double stack buffer for i.MX RT-based boards, prune panic! allocations r=bradjc a=mciantyre ### Pull Request Overview This pull request doubles the stack buffer for boards that use i.MX RT chips. #2311 added board-based peripheral initialization for i.MX RT boards. We use more stack space (at least ~2KiB, most memory for GPIO pins) to initialize the static peripherals, which might exceed the stack buffer once the kernel starts running. Doubling the stack size seems to suffice for running the kernel and two applications on a Teensy 4.0. This approach is similar to #2223, which noted the issue in STM32 boards. I first bisected the issue down to a commit in #2334. After that compiler update, I couldn't run the Tock kernel on the Teensy 4.0. But it turns out that, after #2311 and before the updated compiler, a `panic!()` would overflow the stack. So this seems to be a latent issue that manifested with a compiler update. The boards' panic handlers were allocating large GPIO ports structures just to access a single LED. This PR fixes that by exposing a constructor for individual GPIO pins, and using that constructor in the panic handler. ### Testing Strategy This pull request was tested by rebasing onto trunk, compiling the kernel for a Teensy 4.0, and using the kernel to run two `libtock-c` example apps. Then, I added a `panic!()` just before the main kernel loop, and showed that the panic handler worked as expected. ### TODO or Help Wanted There may be other boards that allocate large objects (GPIO ports and pins) in the panic handler. See the [stm32f3discovery board](https://github.com/tock/tock/blob/86079650ae9d2e5b7287571a2219050c76aa3f1c/boards/stm32f3discovery/src/io.rs#L72) and the [stm32f412gdiscovery board](https://github.com/tock/tock/blob/86079650ae9d2e5b7287571a2219050c76aa3f1c/boards/stm32f412gdiscovery/src/io.rs#L74) for two examples. Are we aware of this behaviors in these boards, or in other boards? ### Documentation Updated - [x] Updated the relevant files in `/docs`, or no updates are required. ### Formatting - [x] Ran `make prepush`. Co-authored-by: Ian McIntyre <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pull Request Overview
This pull request fixes the stack size requirement for STM32F4 boards. Due to the new board instantiation #2188, the required stack size has to be doubled as @hudson-ayers suggested in #2188 (comment).
Testing Strategy
This pull request was tested using an STM32f412GDiscovery board.
TODO or Help Wanted
@krady21, @cosmindanielradu19, @teonaseverin please test using the
STM32F3Discovery andNucleo. Running the blink app is just enough.Documentation Updated
/docs, or no updates are required.Formatting
make prepush.