-
-
Notifications
You must be signed in to change notification settings - Fork 461
add support for NXP MCXN947 #3386
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
base: master
Are you sure you want to change the base?
Conversation
cc: @i509VCB |
The following changelog fragments do not match the expected pattern:
Files should start with one of the categories followed by a dash, and end with '.md' Valid categories are:
|
The following changelog fragments do not match the expected pattern:
Files should start with one of the categories followed by a dash, and end with '.md' Valid categories are:
|
8209ad4
to
52bb10b
Compare
type: armv8m | ||
core_access_options: !Arm | ||
ap: !v1 0 | ||
# - name: cm33_core1 |
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.
Why is the second core commented out?
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.
when it's there probe-rs
can't halt the second core so it fails, but I'm not sure what's the reason:
└─> RUST_LOG=info cargo r --bin probe-rs -- run --chip MCXN947 /media/big/coding/lrtic/target/thumbv8m.main-none-eabihf/debug/lrtic
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.23s
Running `target/debug/probe-rs run --chip MCXN947 /media/big/coding/lrtic/target/thumbv8m.main-none-eabihf/debug/lrtic`
INFO probe_rs::config::target: Using sequence Arm(MCX { variant: "MCXN947" })
INFO attach: probe_rs::probe::cmsisdap: Using protocol SWD
INFO probe_rs::vendor::nxp::sequences::mcx: debug port start for MCX variant: MCXN947
INFO probe_rs::architecture::arm::communication_interface: Debug Port version: DPv2 MinDP: NotImplemented
INFO probe_rs::session: Halting core 0...
INFO probe_rs::session: Halting core 1...
INFO session_drop: probe_rs::session: Core 0 already halted
INFO session_drop: probe_rs::session: Halting core 1...
WARN session_drop: probe_rs::session: Could not clear all hardware breakpoints: An ARM specific error occurred.
Caused by:
A timeout occurred during an operation.
INFO probe_rs::architecture::arm::sequences: Powering down debug port Default
Error: Connecting to the chip was unsuccessful.
Caused by:
0: An ARM specific error occurred.
1: A timeout occurred during an operation.
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.
Hi, Core1 is disabled by default, so maybe it's normal for a timeout error.
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.
Hi, Core1 is disabled by default, so maybe it's normal for a timeout error.
I see, so should probe-rs
enable the core?
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.
No, probe-rs should correctly detect that it can't work with a core and shouldn't fail.
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'm not familiar with the code that resets the cores, so I'm not sure, but maybe I could take a glance at it later
good catch tho
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 is something that has been a long standing issue on the probe-rs end. we unlock all cores in sequences for multicore usually. but technically that's neither required nor always preferred.
The problem is that it's not really obvious how to design an API that unlocks on demand because of ownership. Core handle 1 cannot just suddenly use Core handle 0 if the handle is owned by someone else than the Session.
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.
would merging this with the commented core be sufficient for now until the required infrastructure for supporting it is added?
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.
Yeah we can definitely do that.
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.
At the same time we should probably open an issue about getting core 1 to work so we don't forget.
@@ -84,6 +96,7 @@ impl MCX { | |||
]; | |||
// const VARIANT_A2: [&str; 3] = ["MCXA16", "MCXA17", "MCXA27"]; | |||
const VARIANT_N: [&str; 1] = ["MCXN"]; | |||
const VARIANT_N0: [&str; 1] = ["MCXN947"]; |
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.
Is 946/547/546 part of these variants? Would be nice to also let those be bootable.
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.
honestly I don't know, maybe @Logiase can answer that question
I will see if their debugging/flashing sequences are the same, if so, then I could maybe merge them into a single variant
52bb10b
to
ffcdba0
Compare
9c0bcdd
to
e858470
Compare
72d0294
to
6b294c0
Compare
- add MCXN947 specific sequence taken from CMSIS pack `.pdsc` file - add the trace clock configuration for MCX VARIANT_A0 (register addresses taken from MCXA153 CMSIS pack's `.pdsc` file)
6b294c0
to
733442c
Compare
ping |
This works great for me when I tried it. Would be great to see in main and the next release. |
.pdsc
file.pdsc
file)I have tested this on the FRDM-MCXN947 board, and it works well
I would be more comfortable if someone tests this on the MCXA MCUs, but it should work anyway
currently this only support a single core, where the MCXN947 has 2 cores, because when the 2nd core is present in the yaml file I get this error:
which is probably due to the 2nd core not being enabled by default, and I'm not sure if there is something missing from my implementation to support this, or if there is something missing from
probe-rs
thanks to the lads on matrix that helped me find the information I needed to implement this
and thanks to @Logiase for working with me, and testing :)