Add a register method and use it when connecting #26
Conversation
valpackett
changed the title
|
Hmm, this always seems to result in an "Overflow" error on my J-Link Base Compact |
At least the J-Link clone I have (serial 123456, HW 7.00, FW "J-Link ARM-OB STM32 compiled Aug 22 2012 19:52:04") absolutely requires a registered connection, at least for SWD usage. Nothing ever gets ACKed otherwise. OpenOCD always calls jaylink_register (with all zeros for info) when the REGISTER capability is present, and jaylink_unregister on exit.
|
Added unregistering ability, and reading big returned connection tables (hopefully should solve your overflow). Currently not sure about ordering requirements… |
|
Now doing both registration and unregistration implicitly \o/ |
| let mut conn = Connection::default(); | ||
| if this.caps.contains(Capability::Register) { | ||
| debug!("Registering connection"); | ||
| this.register(&mut conn)?; |
There was a problem hiding this comment.
What happens if the device runs out of connections? Is that something that can happen? Will it reject new connections from being registered or will older ones be dropped automatically?
(this is something that could easily happen when an app either calls process::exit or is killed via Ctrl+C)
There was a problem hiding this comment.
On my old-clone-firmware-whatever device, it never runs out of connections. It always has four, and newer ones just overwrite older ones, it's like a 4-size ring buffer.
There was a problem hiding this comment.
Okay, good. I was going to test this on my (original) J-Link but noticed that the list example is failing with <USB error while reading from device: Overflow>, so it looks like this doesn't work anymore with some hardware? (this is a J-Link Base Compact version 10.1)
There was a problem hiding this comment.
hm. Where is it failing? Is that after receiving the reply for registration? If so, can you dump the lengths (after // Receive connection table) and/or the whole received buf?
There was a problem hiding this comment.
It's just the read of 76 Bytes failing:
[2021-07-25T12:15:04Z DEBUG jaylink] Registering connection
[2021-07-25T12:15:04Z TRACE jaylink] write 14 bytes: [9, 64, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
[2021-07-25T12:15:04Z TRACE jaylink] reading 76 bytes
Bus 001 Address 029 Port 003: VID=1366 PID=0105 – <USB error while reading from device: Overflow>
There was a problem hiding this comment.
huh, so it is an actual USB level error? hmm. Does OpenOCD work with this device?
There was a problem hiding this comment.
Yes, it should work. I believe we need to change how reads/writes work, because libjaylink seems to use an extra buffer, while we directly call into libusb (which will refuse to read more than 76 Bytes into the 76 Byte buffer). You might not be hitting this problem because the clone firmware always returns a fixed-length response here.
There was a problem hiding this comment.
Yes, the FW I have always returns 76. Hmm. I guess we could use an arbitrary big buffer just for this? ¯\_(ツ)_/¯
At least the J-Link clone I have (serial 123456, HW 7.00, FW "J-Link ARM-OB STM32 compiled Aug 22 2012 19:52:04") absolutely requires a registered connection, at least for SWD usage. Nothing ever gets ACKed otherwise.
OpenOCD always calls jaylink_register (with all zeros for info) when the REGISTER capability is present.
https://github.com/ntfreak/openocd/blob/bd1adcffe7f3e51f490bf57889e7454816661196/src/jtag/drivers/jlink.c#L778-L795
Had to spend quite some time trying to debug the JTAG-to-SWD sequence >_< then tried to resend various other things OpenOCD was sending before it… and there it is