Thanks! Have you by chance verified whether the flash algos actually work? I have a slight worry that we may connect to the M0+ core by default, and if the algos are written for M4 there might be problems. You can also constrain the algorithms to the M4 core, but currently I'd recommend just commenting out the M0+ cores.

I currently just start to develop a new application, so I just start to do something with the new chip, but:
It looks like you're right:

$ cargo flash --chip LPC54102J512BD64
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.02s
    Flashing /home/jfrimmel/git/testapp/target/thumbv7em-none-eabihf/debug/testapp
      Erasing ✔ [00:00:00] [########################################] 32.00 KiB/32.00 KiB @ 132.88 KiB/s (eta 0s )
  Programming ✔ [00:00:00] [###########################################] 5.00 KiB/5.00 KiB @ 10.06 KiB/s (eta 0s )    Finished in 0.794s
 WARN probe_rs::architecture::arm::core::armv6m: Expected core to be halted, but core is running

Notice the armv6m in the warning message. If i comment out the Cortex-M0+ core as you suggested, the warning disappears.

$ cargo flash --chip LPC54102J512BD64
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.04s
    Flashing /home/jfrimmel/git/testapp/target/thumbv7em-none-eabihf/debug/testapp
      Erasing ✔ [00:00:00] [########################################] 32.00 KiB/32.00 KiB @ 121.12 KiB/s (eta 0s )
  Programming ✔ [00:00:00] [############################################] 5.00 KiB/5.00 KiB @ 9.06 KiB/s (eta 0s )    Finished in 0.873s

Thus a general question arises: how does probe-rs deal with multi-core-chips (running from the same flash/RAM)?

Thus a general question arises: how does probe-rs deal with multi-core-chips (running from the same flash/RAM)?

The important bits right now are that the default core is the first that is defined in the target YAML, so switching their order might work. All cores are accessable with Session::core(), and calling that will attach to the specified core for a short while. That being said, not much in the CLI tooling actually does anything with multiple cores, and IIRC neither does the VSCode debugger.

Would you like to:

• switch the cores
• comment out the Cortex-M0
• remove the Cortex-M0 entirely
• close this PR as rather there is no target than a half-baked one?

I'm in favor of one of the first two, though.

I'm perfectly happy with switching the order of the cores. Limited support is better than no support :)

Oh, no... I did some testing locally and even with the cores changed, the "wrong" core is used:

$ cargo flash --chip LPC54102J512BD64
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.03s
    Flashing /home/jfrimmel/git/testapp/target/thumbv7em-none-eabihf/debug/testapp
      Erasing ✔ [00:00:00] [########################################] 32.00 KiB/32.00 KiB @ 133.45 KiB/s (eta 0s )
  Programming ✔ [00:00:00] [###########################################] 5.00 KiB/5.00 KiB @ 10.11 KiB/s (eta 0s )    Finished in 0.791s
 WARN probe_rs::architecture::arm::core::armv6m: Expected core to be halted, but core is running

As you can see, there is the armv6m again...

Therefore I'll go one and comment out the Cortex-M0+.

(sorry for the noise)

I'm not sure if that warning is too important here. It might be that the M0+ needs some special attention and we'll need to add a custom debug sequence for these chips, but also warnings aren't errors. As long as the flash algo runs on the main core, and things seem to work (i.e. for example probe-rs run or cargo embed can show RTT output), it should be okay. cargo flash isn't the best tool to test this because it disconnects after flashing and we can't see what happens in the longer term. That being said, if that warning is spammed multiple times a second, it's probably a different story 😅

Multi-core chips are slightly tricky because halting/resuming them is completely implementation-specific. Multi-architecture may or may not throw one more wrench into the story.

Okay, here is a minimal application with RTT output:

#[cortex_m_rt::entry]
fn main() -> ! {
    rtt_target::rtt_init_print!();
    rtt_target::debug_rprintln!("Hello, world!");

    cortex_m_semihosting::debug::exit(cortex_m_semihosting::debug::EXIT_SUCCESS);
    loop {
        unsafe { core::arch::asm!("wfe") };
    }
}

I've done two tests:

So I would deduce, that we do need to comment out the Cortex-M0+ core, as at least some tools will pick the wrong core.