-
Notifications
You must be signed in to change notification settings - Fork 247
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
esp-backtrace: Add coredump
feature
#2672
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a first round of review, I think I'll have some more thoughts later.
Generally looks good! I'm just wondering whether all the coredump stuff belongs inside esp-backtrace, it looks fairly generic. Maybe it might be better to split it out?
esp-backtrace/src/lib.rs
Outdated
println!(""); | ||
println!(""); | ||
println!(""); | ||
println!("{}", defmt::Display2Format(info)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We shouldn't do this unless we really have to, it pulls in core::fmt
machinery
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't new, just the diff is weird.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
esp-backtrace/src/coredump.rs
Outdated
writer.writer.write(®_info_bytes); | ||
} | ||
|
||
pub trait Writer { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we should use embedded-io::Write
here instead of defining our own trait? Maybe it makes dumping the core dump through some other means other than serial possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was thinking if this is a good idea - only reason to have this trait is the dependency count but I think embedded-io doesn't pull transitive dependencies
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unstable esp-hal already pulls in embedded-io
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 true - I guess my concerns about increasing build times is not a real world problem in general
esp-backtrace/src/lib.rs
Outdated
@@ -11,6 +11,30 @@ use esp_println as _; | |||
|
|||
const MAX_BACKTRACE_ADDRESSES: usize = 10; | |||
|
|||
#[cfg(feature = "esp32")] | |||
const RAM: (u32, u32) = (0x3FFA_E000, 0x4000_0000); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we should define these in esp-metadata, and use them from there. We also have a similar set of const
's in the soc
module of esp-hal
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's probably a good thing - also depending on esp-metadata
is not too bad (in general I'd like to not have too much dependencies here)
t.b.h. I implemented that functionality in its own library initially (just had features instead of I was a bit concerned about a bump in build time (same reason for not using embedded-io and esp-metadata - ok I didn't even think about esp-metadata before :) ) |
I think extracting the coredump generation into its own crate makes sense but where should it live? In the esp-hal repo as |
61817c6
to
3661c21
Compare
@@ -37,6 +37,11 @@ pub(crate) fn psram_range() -> Range<usize> { | |||
} | |||
} | |||
|
|||
/// The lower bound of the system's DRAM (Data RAM) address space. | |||
const SOC_DRAM_LOW: usize = esp_config::esp_config_int!(usize, "REGION-DRAM-START"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think (ab)using the esp-config macro should be fine
@@ -75,3 +75,5 @@ symbols = [ | |||
"pm_support_touch_sensor_wakeup", | |||
"ulp_supported", | |||
] | |||
|
|||
memory = [{ name = "dram", start = 0x3FFA_E000, end = 0x4000_0000 }] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we can and should define all memory regions here later and even use them in e.g. the linker scripts
(But that is definitely out of scope for this PR)
pub const SOC_DRAM_LOW: usize = 0x4080_0000; | ||
/// The upper address boundary for system DRAM. | ||
pub const SOC_DRAM_HIGH: usize = 0x4088_0000; | ||
/// The lower bound of the system's DRAM (Data RAM) address space. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe all of these constants should come from esp-metadata some day
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the idea 👍
|
@@ -2,7 +2,7 @@ | |||
name = "esp-backtrace" | |||
version = "0.14.2" | |||
edition = "2021" | |||
rust-version = "1.76.0" | |||
rust-version = "1.79.0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
needed by esp-metadata
|
||
// Define env-vars for all memory regions | ||
for memory in self.memory() { | ||
println!( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we also generate has_<memory_region>_region
config symbols?
c13c544
to
ac4b839
Compare
Thank you for your contribution!
We appreciate the time and effort you've put into this pull request.
To help us review it efficiently, please ensure you've gone through the following checklist:
Submission Checklist 📝
cargo xtask fmt-packages
command to ensure that all changed code is formatted correctly.CHANGELOG.md
in the proper section.Extra:
Pull Request Details 📖
Description
Adds the features
coredump
andcoredump-all
which will make the panic handler to raise an exception (viaecall
/syscall
) and changes the exception handler to create a coredump.Testing
Add the
coredump
feature toesp-backtrace
inexamples
, change one of the examples to panic.You can use https://github.com/bjoernQ/espflash-coredump and a recent espfalsh commit (or copy paste, convert from hex to binary)