jonas-schievink / jaylink Goto Github PK

• JTAG
• SWD

The JLinkGDBServer will reject speeds below 4 kHz saying they're too low. After setting a 1 kHz speed I've observed the generated clock to be extremely bad, so we should forbid that too:

The JLink on the nrf9160-dk does not work with latest master.

Apparently it doesn't support JTAG, so this line fails:

Logs from probe-rs-cli info: https://gist.github.com/Dirbaio/6c79a3e77b91fdf04b00d6170243908e

...and since swd_io and jtag_io will call it, they'll revert to the default speed, even if the user set the speed beforehand.

For example, we could provide:

• Methods to read/write DPs/APs
• A method for generating the SWJ sequence

If we want to put in a lot of effort, we could even provide:

• RTT implementation

There's a second issue that I discovered yesterday with the same old JLink-OB clone probes.

Although probe is detected correctly after connection, it fails to work and reports the lack of response from target:

> ./list
Found 1 J-Link device.

Bus 006 Address 058 Port 004: VID=1366 PID=0101 – SEGGER J-Link (Serial 000000123456)
⤷ Capabilities: GetHwVersion | ReadConfig | WriteConfig | GetMaxBlockSize | GetHwInfo | ResetStopTimed | SelectIf | GetCounters | GetCpuCaps | ExecCpuCmd | Swo | Register | GetCapsEx
  Firmware: J-Link ARM-OB STM32 compiled Aug 22 2012 19:52:04
  HW Version: J-Link 7.0.0
  Max. SWO Speed: 4500000 Hz
  Max. Memblock: 11288 bytes
  VTref: 3.3 V
  Interfaces:
      - JTAG (up to 12 MHz)
      - SWD (up to 12 MHz)

> ./swdump
speed configuration: 12000 kHz
error: no response from target chip

> ./swdump
speed configuration: 12000 kHz
error: no response from target chip

Then I start and terminate (hit Ctrl+C) the official proprietary JLink tool (I want to get rid of this piece of non-free software, that's why I'm trying to learn how to use your library), it shows that both probe and target are OK:

> JLinkGDBServer -halt -if SWD -device STM32F030F4
SEGGER J-Link GDB Server V5.02f Command Line Version

JLinkARM.dll V5.02f (DLL compiled Oct  2 2015 20:53:57)

-----GDB Server start settings-----
GDBInit file:                  none
GDB Server Listening port:     2331
SWO raw output listening port: 2332
Terminal I/O port:             2333
Accept remote connection:      yes
Generate logfile:              off
Verify download:               off
Init regs on start:            off
Silent mode:                   off
Single run mode:               off
Target connection timeout:     0 ms
------J-Link related settings------
J-Link Host interface:         USB
J-Link script:                 none
J-Link settings file:          none
------Target related settings------
Target device:                 STM32F030F4
Target interface:              SWD
Target interface speed:        1000kHz
Target endian:                 little

Connecting to J-Link...
J-Link is connected.
Firmware: J-Link ARM-OB STM32 compiled Aug 22 2012 19:52:04
Hardware: V7.00
S/N: 20090928
Feature(s): RDI,FlashDL,FlashBP,JFlash,GDBFull
Checking target voltage...
Target voltage: 3.30 V
Listening on TCP/IP port 2331
Connecting to target...Connected to target
Waiting for GDB connection...^C

And then I run swdump again and... it works too:

> ./swdump
speed configuration: 12000 kHz
DPIDR=0x0BB11477
CTRL/STAT=0xF0000040

It works until I disconnect and connect my probe again, then I have to run JLinkGDBServer again. I know this report is incomplete without traces / USB communication dumps but probably someone saw this behavior too and already know the answer.

Hey :)

Would you mind cutting a new release? This would allow us to use rusb 0.9.0 in probe-rs.
I would prepare a PR if you are open to it :)

Best,
Noah

Tested on a J-Link Base Compact, it seems that FINE requires special handling and will somehow hang the probe when selected.

I don't really care about FINE, and don't have any chips that speak it, so I'll just note this in the docs for now.

GitHub Actions, probably? It's important that this works on Windows, libusb isn't trivial.

They should hint at installing the WinUSB driver.

Additionally we should check out usbdk, which doesn't require replacing the original J-Link driver. Let's hope it has a reasonable installer that's nicer than Zadig...

It would be nice to have SWD Multidrop support so that RP2040s could be debugged with the J-Link in Rust. Issue probe-rs/probe-rs#1157 has some more details.

Hi!

I've tried your library with a cheap JLink-OB clone (that is working fine with both OpenOCD and proprietary JLinkGDBServer) and came across the following problem:

> ./list 
Found 1 J-Link device.

Bus 006 Address 054 Port 003: VID=1366 PID=0101 – SEGGER J-Link (Serial 000000123456)
⤷ <device is missing capabilities (SpeedInfo) for operation>

Of course, examples refused to work with the same error message.

After removing self.require_capability(Capability::SpeedInfo)?; from read_speeds in src/lib.rs it starts working:

> ./list
Found 1 J-Link device.

Bus 006 Address 054 Port 003: VID=1366 PID=0101 – SEGGER J-Link (Serial 000000123456)
⤷ Capabilities: GetHwVersion | ReadConfig | WriteConfig | GetMaxBlockSize | GetHwInfo | ResetStopTimed | SelectIf | GetCounters | GetCpuCaps | ExecCpuCmd | Swo | Register | GetCapsEx
  Firmware: J-Link ARM-OB STM32 compiled Aug 22 2012 19:52:04
  HW Version: J-Link 7.0.0
  Max. SWO Speed: 4500000 Hz
  Max. Memblock: 11288 bytes
  VTref: 3.3 V
  Interfaces:
      - JTAG (up to 12 MHz)
      - SWD (up to 12 MHz)

It looks like a dirty hack but it works. I wonder what do you think about this issue.

We're planning to make a new probe-rs release soon, and would need a new jaylink release for that. Unfortunately, we cannot use the released version due to a conflict between the different rusb versions in jaylink and probe-rs. Using an older rusb version is not an option due to bugs.

Are you planning to create a new release soon?

Not sure if this is an issue with the J-Link software too, but if the device is plugged in and then accessed before it can "settle" (eg. by running cargo run --example list), USB errors can happen and the device can even reenumerate on the bus.

This might be an issue with how we do USB initialization, but could also be a firmware bug.

Tested on an EFM32 Giant Gecko dev board.

We currently have methods for setting the states of the TMS and TDI pins. There's also commands for controlling TRST and RESET which aren't currently exposed. It should be trivial to add them, but the docs should clarify whether true means high or low and whether the signal is active-high or -low.

All these functions also need to be tested on hardware.

Nice crate! Are there any plans for implementing SWO capture?

Hi! I was wondering how I could add cJTAG support to the project such that I can use with rust embedded toolchain.
Not sure if this is the place to ask this, but could you point me out in the correct direction such that I can help implement it?
I will gladly create a PR then!

This was mentioned in #6 but not fixed by #21 so I wanted to open an issue to keep tracking the idea.

Using libusb on windows requires replacing a device's driver with a libusb one, e.g. using Zadig.

https://github.com/daynix/UsbDk could be used instead, which detaches the device from its drivers and Windows' PNP stack at runtime allowing the device to be controlled without needing to replace its driver.