Skip to content

stm32u5: set panic resources - #4972

Open
alexandruradovici wants to merge 3 commits into
tock:masterfrom
OxidosAutomotive:stm32u5/panic_resources
Open

stm32u5: set panic resources#4972
alexandruradovici wants to merge 3 commits into
tock:masterfrom
OxidosAutomotive:stm32u5/panic_resources

Conversation

@alexandruradovici

@alexandruradovici alexandruradovici commented Jul 22, 2026

Copy link
Copy Markdown
Contributor

Pull Request Overview

This pull request:

  • fixes the setting of the panic resources for the stm32u5
  • adds some debug messages to the panic printers to print messages when information is not available
  • enables some of the missing GPIO pins
  • adds the printing of the kernel startup banner
  • fixes the Cortex M33 fault state printing function

We forgot to set the PANIC_RESOURCES fields for the stm32u5 board and the panic handler was not printing the correct information. Initially we thought it was a UART issue, just to figure out that we forgot to initialise the fields.

This PR adds some messages that clearly state of those fields are not available.

Testing Strategy

This pull request was tested by @alexandruradovici.

TODO or Help Wanted

N/A

Checklist

  • Ran make prepush.

PR Contents

Documentation

  • Updated the relevant files in /docs and the Book.
  • No documentation updates are required.

AI Use

  • No AI was used in this PR.
  • AI was used in this PR. I have read Tock's AI policy and have properly disclosed my AI use below.

Comment thread kernel/src/debug.rs Outdated
Comment thread kernel/src/debug.rs
Comment on lines +386 to 389
} else {
let _ = writer.write_str("\r\nNo loaded processes\r\n");
}
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure we need to print that there are no processes here, as the caller can/should check instead.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We did no check the process and thought that the panic print was stuck. While for UART panic this is usually not the case (being stuck), USB CDC panics could actually get stuck.

Comment thread kernel/src/debug.rs Outdated
Comment on lines 363 to 365
@@ -353,21 +365,27 @@ pub unsafe fn panic_process_info<PP: ProcessPrinter, W: Write>(
process_printer: Option<&'static PP>,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if instead we could make this not an option and have the caller have to decide what to do.

@alexandruradovici alexandruradovici Jul 24, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works for me, this would make the caller check. I modified it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants