JtagGetIdcodeError

[David-OConnor]

Hi. Where should I start debugging this? On STM32F3, and switching from openocd:

    Finished release [optimized + debuginfo] target(s) in 23.16s
     Running `probe-run --chip STM32F303CCTx target\thumbv7em-none-eabihf\release\anyleaf_watermonitor`
Error: An error with the usage of the probe occured

Caused by:
    0: An error specific to a probe type occured
    1: Command failed with status JtagGetIdcodeError
error: process didn't exit successfully: `probe-run --chip STM32F303CCTx target\thumbv7em-none-eabihf\release\anyleaf_watermonitor` (exit code:
 1)

./cargo/config:

[target.'cfg(all(target_arch = "arm", target_os = "none"))']
runner = "probe-run --chip STM32F303CCTx" # to list chips, run `probe-run --list-chips.`
rustflags = [
  "-C", "link-arg=-Tlink.x",
]

[build]
target = "thumbv7em-none-eabihf"

edit: After removing the

rustflags = [
  "-C", "link-arg=-Tlink.x",
]

line, the error is Error:.vector_tablesection is missing.

[japaric]

Command failed with status JtagGetIdcodeError

This looks like a probe-rs error during the early stages of the connection with the debugger. Please run probe-rs-cli info (with debugger, microcontroller and PC all connected). If that command fails then run RUST_LOG=probe_rs=debug probe-rs-cli info and report that to the probe-rs issue tracker (https://github.com/probe-rs/probe-rs). Commands should look like this:

$ cargo install probe-rs-cli # if not already installed
$ probe-rs-cli info
$ RUST_LOG=probe_rs=debug probe-rs-cli info # if the previous command failed

If probe-rs-cli info works then run RUST_LOG=probe_rs=debug cargo run --release --bin anyleaf_watermonitor (or the Cargo command in your issue description) and report the logs in this thread.

[David-OConnor]

edit: If I add back the rustflag args, it's working now. No idea.

[japaric]

edit: After removing the

sorry, I missed your edit in the issue description. You should always keep those rustflags in .cargo/config. Also you should not set the RUSTFLAGS variable as that would break the linking.

it's working now. No idea.

We have seen spurious errors from probe-rs when using the JLink before. Different error message but the error happened only once on the first probe-rs connection. We think it may have been a timeout on the probe-rs being too short but were unable to debug further since the error only occurred once.

For statistics sake, what probe are you using the STM32 chip? JLink? ST-Link? CMSIS-DAP? If unsure you can run probe-rs-cli list

[David-OConnor]

ST-Link. I had the message pop up once after - the fix was resetting the device.

[coreychristian]

I get this error, anyone able to give me some pointers?

RUST_LOG=probe_rs=debug probe-rs-cli info DEBUG probe_rs::probe::daplink::tools > Attempting to open 0483:3748 in CMSIS-DAP v1 mode DEBUG probe_rs::probe::stlink::usb_interface > Acquired libusb context. DEBUG probe_rs::probe::stlink::usb_interface > Aquired handle for probe DEBUG probe_rs::probe::stlink::usb_interface > Active config descriptor: ConfigDescriptor { bLength: 9, bDescriptorType: 2, wTotalLength: 39, bNumInterfaces: 1, bConfigurationValue: 1, iConfiguration: 0, bmAttributes: 128, bMaxPower: 50, extra: None } DEBUG probe_rs::probe::stlink::usb_interface > Device descriptor: DeviceDescriptor { bLength: 18, bDescriptorType: 1, bcdUSB: 512, bDeviceClass: 0, bDeviceSubClass: 0, bDeviceProtocol: 0, bMaxPacketSize: 64, idVendor: 1155, idProduct: 14152, bcdDevice: 256, iManufacturer: 1, iProduct: 2, iSerialNumber: 3, bNumConfigurations: 1 } DEBUG probe_rs::probe::stlink::usb_interface > Claimed interface 0 of USB device. DEBUG probe_rs::probe::stlink::usb_interface > Succesfully attached to STLink. DEBUG probe_rs::probe::stlink > Initializing STLink... DEBUG probe_rs::probe::stlink > Current device mode: Dfu DEBUG probe_rs::probe::stlink > STLink version: (2, 36) DEBUG probe_rs::probe::stlink > attach(Swd) DEBUG probe_rs::probe::stlink > Current device mode: MassStorage DEBUG probe_rs::probe::stlink > Switching protocol to SWD WARN probe_rs::probe::stlink > check_status failed: JtagGetIdcodeError DEBUG probe_rs::probe::stlink > Current device mode: MassStorage Error: An error with the usage of the probe occured

Caused by: 0: An error specific to a probe type occured 1: Command failed with status JtagGetIdcodeError

probe-rs-cli list The following devices were found: [0]: STLink V2 (VID: 0483, PID: 3748, Serial: 3E4501002A135937334D4E00, STLink)

[japaric]

@coreychristian I would suggest opening a new issue and including the information I requested in this comment https://github.com/knurling-rs/probe-run/issues/27#issuecomment-677470283

[coreychristian]

Thank you, I will do that, but first I want to rule out a hardware issue before I waste anyone's time with it. I am not able to connect probe-rs, OpenOCD or STM's ST-Link to the board. The only connection I am able to make to the board is via the USART interface using STM's Demonstrator, so I think either the board or my ST-Link clone is faulty. And the log above is from the command you referred me to (that's where I got the idea from thanks).

[barafael]

This very same error occurs when the STLinkV2 on my stm32f446 nucleo is disconnected from the actual chip by the jumpers. That is to say, always make sure to actually connect the debug probe :)

[milesgranger]

For me, the world's okayest noob, I had set the clock speed set incorrectly; 8Hz instead of 8MHz :face_exhaling:

let clocks = rcc.cfgr.hclk(8_u32.Hz()).freeze(&mut flash.acr, &mut pwr);

should have been

let clocks = rcc.cfgr.hclk(8_u32.MHz()).freeze(&mut flash.acr, &mut pwr);