Skip to content

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

BKSalman
Copy link

@BKSalman BKSalman commented May 28, 2025

  • 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)

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:

└─> 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.

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 :)

@BKSalman
Copy link
Author

cc: @i509VCB

Copy link

The following changelog fragments do not match the expected pattern:

  • changelog/mcxa-trace-clock-configuration.md

Files should start with one of the categories followed by a dash, and end with '.md'
For example: 'added-foo-bar.md'

Valid categories are:

  • added
  • changed
  • fixed
  • removed

Copy link

The following changelog fragments do not match the expected pattern:

  • changelog/mcxa-trace-clock-configuration.md

Files should start with one of the categories followed by a dash, and end with '.md'
For example: 'added-foo-bar.md'

Valid categories are:

  • added
  • changed
  • fixed
  • removed

@BKSalman BKSalman force-pushed the mcxn947-support branch 2 times, most recently from 8209ad4 to 52bb10b Compare May 28, 2025 10:12
type: armv8m
core_access_options: !Arm
ap: !v1 0
# - name: cm33_core1
Copy link
Member

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?

Copy link
Author

@BKSalman BKSalman May 28, 2025

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.

Copy link
Contributor

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.

Copy link
Author

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?

Copy link
Contributor

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.

Copy link
Author

@BKSalman BKSalman Jun 15, 2025

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

Copy link
Member

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.

Copy link
Author

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?

Copy link
Member

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.

Copy link
Contributor

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"];
Copy link
Contributor

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.

Copy link
Author

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

@BKSalman BKSalman requested a review from Yatekii June 28, 2025 07:49
@BKSalman BKSalman force-pushed the mcxn947-support branch 2 times, most recently from 9c0bcdd to e858470 Compare July 1, 2025 11:33
@BKSalman BKSalman force-pushed the mcxn947-support branch 2 times, most recently from 72d0294 to 6b294c0 Compare July 13, 2025 12:48
- 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)
@BKSalman
Copy link
Author

ping

@SpinFast
Copy link
Contributor

SpinFast commented Jul 24, 2025

This works great for me when I tried it. Would be great to see in main and the next release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy