Cargo embed issue

Embedded
1

I am trying to flash my rust program with cargo embed on MimxRT064 board by NXP which is supported by probe-rs , I usually get the DAPLink listed on my list like this:

[0]: DAPLink CMSIS-DAP -- 0d28:0204:023200001A2D657900000000000000000000000097969905 (CMSIS-DAP)

but when i try cargo embed i get this error:
Error Failed to open the debug probe.

         Caused by:
             0: The debug probe could not be created.
             1: The selected debug probe was not found.
                This can be due to permissions.

I am using the built in debugger in the board and my machine is windows

2

if the command line probe-rs can detect the probe, it's probably a configuration error. what is the content of your Embed.toml?

3

I am not having an Embed.toml , I felt the memory.x and debug.gdb file were enough, can you let me know what is the file structure of Embed.toml? thanks in advance

4

I have made an Embed.toml file which looks like this:

[default.general]
chip = "MIMXRT1064"

[default.rtt]
enabled = true

it still doesnt work

5

the important configuration is the target chip model name, and the probe VID and PID.

if the proble selector is not set, it will automatically detect connected probe, which should work in most cases, in which only a single probe is connected to the computer.

but for some reason, it cannot connect to your proble.

just to make sure probe-rs can recognize your probe, what's the output of the command "probe-rs info"? also, can you check whether cargo flash works? for example. try run cargo flash --chip MIMXRT1064

6

How does probe-rs know which port to use in a multiport FTDI-chip? Or is that why they only support a limited set of FTDI-based probes?

7

It gives the same error as before , fyi i am using the built-in debug probe in the development board and there is only one probe connected to my PC

8

I have not used any FTDI based probe, I'm not sure what "port" is referring to, but probe-rs tries to detect probes based on the USB VID&PID (and serial number too, if there are multiple devices of the same ID). and based on the log messages, it seems all good: 0d28:0204 is recognized to support the ARM CMSIS-DAP protocol.

that should be auto detected, in theory. but maybe FTDI chips are different, as you indicated? can you show the output of the commands below:

$ probe-rs list
$ probe-rs info
9

The probe-rs list output is in the first comment highlighted in code, ( A DAPLink ) , as i don't have access to my work laptop and the hardware fro the next 2 days I am not sure what probe-rs info really showed as an output, can you let me know what is ideally to be the output with this command?

10

it's strange that you had this proble, as DAPLink should be perfectly supported. but just in case it's a problem during the probe auto detection, maybe try to explicit specify the VID and PID in Embed.toml, like this:

[default.probe]
usb_vid = "0d28"
usb_pid = "0204"
protocol = "Jtag"

it enumerate all TAPs accessible by the probe. example output looks like this:

$ probe-rs info
Probing target via SWD

ARM Chip with debug port Default:
Debug Port: DPv1, DP Designer: ARM Ltd
└── 0 MemoryAP
    └── ROM Table (Class 1), Designer: STMicroelectronics
        ├── Cortex-M4 SCS   (Generic IP component)
        │   └── CPUID
        │       ├── IMPLEMENTER: ARM Ltd
        │       ├── VARIANT: 0
        │       ├── PARTNO: Cortex-M4
        │       └── REVISION: 1
        ├── Cortex-M3 DWT   (Generic IP component)
        ├── Cortex-M3 FBP   (Generic IP component)
        ├── Cortex-M3 ITM   (Generic IP component)
        ├── Cortex-M4 TPIU  (Coresight Component)
        └── Cortex-M4 ETM   (Coresight Component)
11

Interesting, I was not aware of this I will try this and update here , thanks

13

probers -info gives this

Error: Failed to open the debug probe.

Caused by:
    0: The debug probe could not be created.
    1: The selected debug probe was not found.
       This can be due to permissions

but the cargo embed commandgives this error now:
Error An error with the flashing procedure has occurred.

         Caused by:
             No flash memory contains the entire requested memory range 0x07000000..0x07000400.

My memory.x :

MEMORY{
FLASH : ORIGIN = 0x70000000,LENGTH = 4M
RAM : ORIGIN = 0x20200000 ,LENGTH = 768K

}
14

add imxrt_ral is now trying to flash the code in , but now i amstuck with this now

 WARN probe_rs::vendor::nxp::sequences::nxp_armv7m: MIMXRT10xx core type supplied as Armv7m, but the actual core is a Armv7em
        Done processing config default
 WARN probe_rs::architecture::arm::core::armv7m: Core is running, but we expected it to be halted
15

it's strange that the address ranges don't match each other. is it just a typo, or your linker didn't pick up the memory.x? do you have multiple memory.x files?

16

Nope just one and I took this address from the MCUExpresso IDE which is usually the tool to flash the C program

17

so I just did some searching, and it turns out the imxrt chips are a bit more complicated than the microcontrollers that I'm familiar with, such as nrf52840, rp2040, or stm32; specifically, the memory map looks way more complex and versatile.

in the "imxrt-rs" book:

https://imxrt-rs.github.io/book/index.html

they mentioned the imxrt-rt runtime, the documentation of which explicitly states:

Link against imxrt-link.x, which is automatically made available on the linker search path. Do not link against link.x from cortex-m-rt.

I took a glimpse at the imxrt-link.x script, and it does NOT include memory.x.

and there's also a section on "boot headers", which I don't understand either, but I did find (probably?) the source code as a linker script

in fact, the runtime is intended to be configured by the app's build script. here's an example presented in the documentation:

// build.rs
use imxrt_rt::{FlexRamBanks, Memory};

fn main() {
    RuntimeBuilder::from_flexspi(FAMILY, FLASH_SIZE)
        .flexram_banks(FlexRamBanks {
            ocram: 0,
            dtcm: FAMILY.flexram_bank_count() / 2 + 2,
            itcm: FAMILY.flexram_bank_count() / 2 - 2,
        })
        .text(Memory::Itcm)
        .vectors(Memory::Itcm)
        .rodata(Memory::Dtcm)
        .data(Memory::Dtcm)
        .bss(Memory::Dtcm)
        .uninit(Memory::Dtcm)
        .stack(Memory::Dtcm)
        .stack_size(4 * 1024)
        .heap(Memory::Dtcm)
        .heap_size(512)
        .build()
        .unwrap();
}

since I don't have the hardware, nor do I have any prior experience with this chip, I can't really understand what these configurations mean.

since it needs special runtime and linker script, I'm not sure whether the code using the generic cortex-m-rt (thus memory.x) would work for this mcu.

I suggest you to join the imxrt-rs chatroom (there's a link at the bottom of the "introduction" chapter of the imxrt-rs book), to chat with the people who actually have the actual hardware and the knowledge.

meanwhile, feel free to continue the discussion on this forum, though you are more likely to get generic advices that are not specific to this mcu.

1 Like
18

Thanks for the hard work i will see if i find a solution and post it here later

19

So I think imxrt_boot_gen crate is the answer to the problem to flash the code correctly with the bootloader, the problem i am having now i very specific which is that I have a different version of the same board which leads to the pin mux configuration to be different than what they have made the crate with. So generally i feel that the board version matters as well

1 Like