Jlink support #9
Labels
enhancement
New feature or request
Comments
What do you mean by binary packages? For which part of the work flow? SEGGER will need to support their own device. Note that you can use a Pico to debug with SWD to another Pico, so at most that is $5 extra expense if you cannot get the SEGGER working. |
I mean the openocd itself, especially for windows. This is helpful for further integration (maybe platformio or something like NOOBS for pico) There are some areas where you can get a jlink ob (absolutely clone) for 3$ and it is probably the most common debug tool for developers. |
|
Yup; we didn't include JLink changes for SWD multidrop because we didn't have anything to test them on, and figured that could be done after we up-streamed our changes. Watch this space, and we'll post something that might work shortly |
|
try the rp2040_jlink branch (as I say untested) |
|
I tried the branch mentioned, the "Sequence not supported errors" disappeared but I'm still unable to successfully run openocd. Output: |
|
Jlink is working for me on branch rp2040_jlink. |
|
I suspect given it works for you and not me, it's a problem with my setup somehow. I attached a logic analyser on the SWD pins and saw no activity when running openocd, so some problem with my cables or JLink Base likely. |
|
May be worth checking the hardware revision of your J-Link, they don't all support multi-drop SWD: https://wiki.segger.com/Software_and_Hardware_Features_Overview |
|
I can confirm the
Edit: New photo showing VTref on 3v3 |
|
I'm able to debug using the jlink branch. However, I'm not able to program with it. Here's my openocd script for programming: which fails with: with |
|
@ep1cman thanks for the photo! I was missing the VTref pin connection. I hadn't soldered those headers on yet, only the SWD ones, not realising it was needed. When looking it up though, I noted that it says it's used a reference for the clock/IO levels. Are those at 3.3v like the rest of the IO? If so, why is that not using the 3.3v out as a reference? I guess it'll work because it's still within the allowable range for a "high" signal? |
|
You are totally right, I wrongly assumed what Vsys was thinking it was 3.3v, I should have read the data sheet better. VTref should indeed be connected to 3.3v to set the J-Link signal voltages. |
|
I can program raspberry just fine but it will always fail on verification at different addresses, it looks like some problem with reading from flash. Also I noticed that reading from 0x10000000 doesn't always work, I assume it requires properly configure XIP_SSI first? Segger will add support for RP2040 in a few days, but it's probably worth to fix it in openocd anayway. |
|
Often that can result from the wiring. You need to ensure that the SWD wires are as short as possible, with nothing in between (for example, I used to have mine set up via a breadboard, but that was unreliable - straight wires from the Pi to the Pico worked fine) |
|
I have my J-Link on macOS 10.14 using this openocd talking to my Pico AND I've arrived at a place where gdb works but I'll have to do it again to figure out if it was luck or skill. |
|
I tried different wiring including soldering directly to the board and I'm still getting verification failed on "monitor program" command (see attached log). I think there is a problem with flash loader in regards to jlink, otherwise debugging and everything else works fine which further confirms its not a wiring. Anyway at 400khz its very unlikely that 5cm wires would be a problem...
|
|
I belive the problem comes from wrong implementation of WAIT response in jlink driver. When WAIT instead of ACK is received at DP/AP transcation transfer is dropped instead of retried. I don't know where error handling should be implemented in jlink driver or higher level drivers, but that seems to be the case. From ADI specification one can read: WAIT response to a DPACC or APACC access A WAIT response indicates that the previous transaction has not completed. Normally, after receiving a WAIT response the host retries the DPACC or APACC access. Note The previous transaction might be either a DP or an AP access. DP accesses are stalled, by returning WAIT, until any previous AP transaction has completed. Normally, if software detects a WAIT response, it retries the same transfer, which enables the protocol to process data as quickly as possible. However, in case an abort mechanism is implemented, if the software has retried a transfer several times, and has waited long enough for a slow interconnect and memory system to respond, it might write to the ABORT register to cancel the operation. This action signals that the active AP must terminate the transfer that it is attempting, to permit access to other parts of the debug system. An AP might not be able to terminate a transfer on its SoC interface. However, on receiving an abort request, the AP must free its interface to the DP. No request is generated at the Update-DR state, and the shifted-in data is discarded. The captured value of ReadResult[31:0] is UNKNOWN. Debug: 114728 217204 jlink.c:526 jaylink_log_handler(): Starting write / read operation (length = 32 / 15 bytes). |
|
Thank you for the very useful tips: I can now use J-Link with OpenOCD to debug against the RP2040. |
|
For people like me wondering where the that jlink branch is: seems like the changes are included in branch rp2040 and the jlink branch was just deleted. I can use branch rp2040 with a J-Link. |
|
So this issue can be closed. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I have a jlink ob with swd port available but it seems not working with the RP2040. I don't understand why, and there is some debug log.
Also please provide some binary packages, as not everyone are familar with compiling the software.
If only this chip can be supported by SEGGER itself，we will be able to use the offical jlink software and it will simplify many steps.
The text was updated successfully, but these errors were encountered: