Raspberry Pi Pico J-Link problem... :(

GDall All :slight_smile:

I’ve recently acquired a Pi Pico and a Segger J-Link EDU mini, but have had a problem uploading a second time to the Pi Pico via J-Link. The EDU mini firmware has also been update.

I’ve also upload and run via pictool ‘binary method’ repeatedly without any problems…

I’ve used the obligatory blinking LED code shown below…

#include <Arduino.h>

void setup() {
  // initialize digital pin LED_BUILTIN as an output.
  pinMode(LED_BUILTIN, OUTPUT);
}

// the loop function runs over and over again forever
void loop() {
  digitalWrite(LED_BUILTIN, HIGH);
  delay(1000);
  digitalWrite(LED_BUILTIN, LOW);
  delay(1000);
}

this is my platformio.ini below…

; PlatformIO Project Configuration File
;
; Build options: build flags, source filter
; Upload options: custom upload port, speed and extra flags
; Library options: dependencies, extra library storages
; Advanced options: extra scripting
;
; Please visit documentation for the other options and examples
; Redirecting...

[env:pico]
;platform = GitHub - platformio/platform-raspberrypi: Raspberry Pi: development platform for PlatformIO
platform = raspberrypi

board = pico
framework = arduino

;upload_protocol = picotool
;upload_port = /dev/ttyACM0

upload_protocol = jlink
;debug_tool = jlink

below is the terminal contents, and the LED Blinking…

Processing pico (platform: raspberrypi; board: pico; framework: arduino)

Verbose mode can be enabled via -v, --verbose option
CONFIGURATION: Redirecting...
PLATFORM: Raspberry Pi RP2040 (1.1.0) > Raspberry Pi Pico
HARDWARE: RP2040 133MHz, 264KB RAM, 2MB Flash
DEBUG: Current (cmsis-dap) External (cmsis-dap, jlink, raspberrypi-swd)
PACKAGES:

  • framework-arduino-mbed 2.1.0
  • tool-jlink 1.72000.0 (7.20.0)
  • tool-openocd-raspberrypi 2.1100.0 (11.0)
  • tool-rp2040tools 1.0.2
  • toolchain-gccarmnoneeabi 1.90201.191206 (9.2.1)
    LDF: Library Dependency Finder → Library Dependency Finder (LDF) — PlatformIO latest documentation
    LDF Modes: Finder ~ chain, Compatibility ~ soft
    Found 28 compatible libraries
    Scanning dependencies…
    No dependencies
    Building in release mode
    Checking size .pio/build/pico/firmware.elf
    Advanced Memory Usage is available via “PlatformIO Home > Project Inspect”
    RAM: [== ] 18.6% (used 50236 bytes from 270336 bytes)
    Flash: [ ] 3.4% (used 71632 bytes from 2097152 bytes)
    Configuring upload protocol…
    AVAILABLE: cmsis-dap, jlink, picotool, raspberrypi-swd
    CURRENT: upload_protocol = jlink
    Uploading .pio/build/pico/firmware.hex
    SEGGER J-Link Commander V7.20 (Compiled Apr 28 2021 17:38:41)
    DLL version V7.20, compiled Apr 28 2021 17:38:26

J-Link Command File read successfully.
Processing script file…

J-Link connection not established yet but required for command.
Connecting to J-Link via USB…O.K.
Firmware: J-Link EDU Mini V1 compiled Jun 7 2021 15:44:25
Hardware version: V1.00
S/N: 801032045
License(s): FlashBP, GDB
VTref=3.226V
Target connection not established yet but required for command.
Device “RP2040_M0_0” selected.

Connecting to target via SWD
ConfigTargetSettings() start
J-Link script: ConfigTargetSettings()
ConfigTargetSettings() end
InitTarget() start
InitTarget() end
Found SW-DP with ID 0x0BC12477
DPIDR: 0x0BC12477
Scanning AP map to find all available APs
AP[1]: Stopped AP scan as end of AP map has been reached
AP[0]: AHB-AP (IDR: 0x04770031)
Iterating through AP map to find AHB-AP to use
AP[0]: Core found
AP[0]: AHB-AP ROM base: 0xE00FF000
CPUID register: 0x410CC601. Implementer code: 0x41 (ARM)
Found Cortex-M0 r0p1, Little endian.
FPUnit: 4 code (BP) slots and 0 literal slots
CoreSight components:
ROMTbl[0] @ E00FF000
ROMTbl[0][0]: E000E000, CID: B105E00D, PID: 000BB008 SCS
ROMTbl[0][1]: E0001000, CID: B105E00D, PID: 000BB00A DWT
ROMTbl[0][2]: E0002000, CID: B105E00D, PID: 000BB00B FPB
Cortex-M0 identified.
PC = 10004036, CycleCnt = 00000000
R0 = 00000001, R1 = 00000001, R2 = 2000C134, R3 = 00000001
R4 = 00000000, R5 = 00000000, R6 = 00000000, R7 = 00000000
R8 = 00000000, R9 = 00000000, R10= 00000000, R11= 00000000
R12= 00000000
SP(R13)= 2000B270, MSP= 2003FFC0, PSP= 2000B270, R14(LR) = 10004037
XPSR = 01000000: APSR = nzcvq, EPSR = 01000000, IPSR = 000 (NoException)
CFBP = 02000001, CONTROL = 02, FAULTMASK = 00, BASEPRI = 00, PRIMASK = 01
FPU regs: FPU not enabled / not implemented on connected CPU.

Downloading file [.pio/build/pico/firmware.hex]…
Comparing flash [100%] Done.
J-Link: Flash download: Bank 0 @ 0x10000000: Skipped. Contents already match
O.K.

Reset delay: 0 ms
Reset type NORMAL: Resets core & peripherals via SYSRESETREQ & VECTRESET bit.
Reset: Halt core after reset via DEMCR.VC_CORERESET.
Reset: Reset device via AIRCR.SYSRESETREQ.

Script processing completed.

===================================== [SUCCESS] Took 3.91 seconds =====================================

On the second J-Link upload, the output is shown below… :frowning:

Processing pico (platform: raspberrypi; board: pico; framework: arduino)

Verbose mode can be enabled via -v, --verbose option
CONFIGURATION: Redirecting...
PLATFORM: Raspberry Pi RP2040 (1.1.0) > Raspberry Pi Pico
HARDWARE: RP2040 133MHz, 264KB RAM, 2MB Flash
DEBUG: Current (cmsis-dap) External (cmsis-dap, jlink, raspberrypi-swd)
PACKAGES:

  • framework-arduino-mbed 2.1.0
  • tool-jlink 1.72000.0 (7.20.0)
  • tool-openocd-raspberrypi 2.1100.0 (11.0)
  • tool-rp2040tools 1.0.2
  • toolchain-gccarmnoneeabi 1.90201.191206 (9.2.1)
    LDF: Library Dependency Finder → Library Dependency Finder (LDF) — PlatformIO latest documentation
    LDF Modes: Finder ~ chain, Compatibility ~ soft
    Found 28 compatible libraries
    Scanning dependencies…
    No dependencies
    Building in release mode
    Checking size .pio/build/pico/firmware.elf
    Advanced Memory Usage is available via “PlatformIO Home > Project Inspect”
    RAM: [== ] 18.6% (used 50236 bytes from 270336 bytes)
    Flash: [ ] 3.4% (used 71632 bytes from 2097152 bytes)
    Configuring upload protocol…
    AVAILABLE: cmsis-dap, jlink, picotool, raspberrypi-swd
    CURRENT: upload_protocol = jlink
    Uploading .pio/build/pico/firmware.hex
    SEGGER J-Link Commander V7.20 (Compiled Apr 28 2021 17:38:41)
    DLL version V7.20, compiled Apr 28 2021 17:38:26

J-Link Command File read successfully.
Processing script file…

J-Link connection not established yet but required for command.
Connecting to J-Link via USB…O.K.
Firmware: J-Link EDU Mini V1 compiled Jun 7 2021 15:44:25
Hardware version: V1.00
S/N: 801032045
License(s): FlashBP, GDB
VTref=3.221V
Target connection not established yet but required for command.
Device “RP2040_M0_0” selected.

Connecting to target via SWD
ConfigTargetSettings() start
J-Link script: ConfigTargetSettings()
ConfigTargetSettings() end
InitTarget() start
InitTarget() end
ConfigTargetSettings() start
J-Link script: ConfigTargetSettings()
ConfigTargetSettings() end
InitTarget() start
InitTarget() end
ConfigTargetSettings() start
J-Link script: ConfigTargetSettings()
ConfigTargetSettings() end
InitTarget() start
InitTarget() end
ConfigTargetSettings() start
J-Link script: ConfigTargetSettings()
ConfigTargetSettings() end
InitTarget() start
InitTarget() end
Cannot connect to target.

Target connection not established yet but required for command.
Device “RP2040_M0_0” selected.


Connecting to target via SWD
ConfigTargetSettings() start
J-Link script: ConfigTargetSettings()
ConfigTargetSettings() end
InitTarget() start
InitTarget() end
ConfigTargetSettings() start
J-Link script: ConfigTargetSettings()
ConfigTargetSettings() end
InitTarget() start
InitTarget() end
ConfigTargetSettings() start
J-Link script: ConfigTargetSettings()
ConfigTargetSettings() end
InitTarget() start
InitTarget() end
ConfigTargetSettings() start
J-Link script: ConfigTargetSettings()
ConfigTargetSettings() end
InitTarget() start
InitTarget() end
Cannot connect to target.

Script processing completed.

===================================== [SUCCESS] Took 6.23 seconds =====================================

After this second upload blinking LED is no more, and the serial port of the Pi Pico disconnects

cdc_acm 2-1.2:1.0: ttyACM0: USB ACM device
usb 2-1.2: USB disconnect, device number 20

It seems that the RP2040 has gone into a low power stupor and only a reset / power cycle will clear the problem, below are shown two pics of current been drawn 1) Actively blinking LED 2) In its stupor…

I’ve gone back to previous platformio posts and elsewhere on the Net, but the problem persists… :frowning:

1 Like

Very interesting behavior. Indeed mbed-os (and the Arduino core is based on that) has an auto-deepsleep feature with its RTX5 RTOS. However, it should still be possible to access the JTAG / SWD interface after that. I also see people debugging with it in here.

I’d suggest to also open an issue in the platform above to get it tracked.

You might be able to get a successful upload again if you press the RESET button at the right time? (Not BOOTSEL, reset)

Hi maxgerhardt

Thx for reply… What I didn’t mention in my post previously is that I also retested 1st a J-Link upload, and LED is blinking and serial port is still connected…

And on my second upload I switched over to the picotools binary upload method with no power cycling and the board was happy to still blink the LED, I did that repeatedly.

I then switched back to J-Link method without power cycling, that upload failed as mentioned in my previous post… No blinky LED and serial port disconnected.

Either Openocd or the EDU mini or RP2040 might be the problem??? I also power cycled the EDU mini on one try, no change…

I’ve seen that debugging post / link, the result seems less than ideal or clear.

If I need to reset or power cycle each time when I use J-Linking then it would not be very useful… :frowning:

Thx again, I continual looking some fix… :slight_smile:

Morning folks :slight_smile:

This morning I discovered a program called ‘SEGGER J-Flash Lite V7.20’ among others that had been installed by PlatformIO when I installed support for Raspberry Pi Pico board…

I used the blinky LED hex file compiled by platformio to directly upload to the Pi Pico board bypassing platformio completely…

The first upload had no problem as shown above as

Downloading… Done

the LED is blinking.

On the second upload the EDU mini reports

ERROR: Could not connect to target.

Blinking LED stops and the serial port disconnects, then it is in it’s lower power stupor.
Only a reset/power cycle will bring it back, blinking the LED code from the first upload.

Registered on Github this morning will open an issue

Power cycle the Raspberry Pi Pico and then flash it.

I can’t recall if a power down was needed before for J-Link but it seems now that with PlatformIO or J-Flash Lite, a Pico reset may not be enough. The power down method works consistently.

I tried to replicate your test with J-Flash Lite, as below.
The ERROR: Could not connect to target. appeared when I tried a Pico reset. Successful download after a power down & reconnect.

We should be able to flash the Pico without a power cycle or a reset of the board.

I have asked platform-raspberrypi dev to look into the issue.

Thx for the reply zpm1066… :slight_smile:

Yes a power cycle is the need to bring it back, then blinking the LED from the hex code uploaded from first successful attempt…

I also tried the the hex file compiled by Arudino IDE 2.0b6, had the same effect. Tried scratching on the Net for a bare metal blink hex file by Raspberry Pi Pico SDK, no luck… I wanted to eliminate MBedOS as a possible cause…

Your test was it with a Pi Pico, or a Tiny2040 as shown in your github post?

The behavior for a regular Raspberry Pi Pico is the same as that of a Tiny2040.

I have also verified using a bare metal hex file generated from the Raspberry Pi Pico SDK and J-Flash Lite. It’s the same behavior.

A power cycle is needed for J-Link. I don’t recall this happening before. It may be a bug in the Segger J-Link firmware that either existed earlier or got introduced. I’ll look into it more and check the Segger Forum.

If the issue appears to be a J-Link bug, I’ll open one up with Segger Support. I already have a J-Link bug related to their micro:bit J-Link OB firmware (to do with LEDs status after replacing CMSIS-DAP with J-Link OB firmware) that they have reproduced and are working on.

I use J-Link Edu Mini probes extensively with the nRF52840, BBC micro:bit v2, and STM32 devices. Other than the Pico, I’ve never had to power cycle a device for J-Link upload or debug with them.

Btw - Where did you get that neat looking USB meter? I have one but it’s a cheap one. Your USB meter looks similar to a FNB38 USB Meter.

It’s a RuiDeng UM25C with bluetooth…

I also have a Arduino Nano RP2040 Contect, it’s swd interface are five tiny pads underneath.
These tiny pads are too small for my aging eyes so soldering was out , so I made a small jig to
fit them. I got the same result as my Pi Pico and your Tiny2040, the jig is a bit touchy. For the
mo haven’t recorded result with J-Link Lite yet…

Was curious if you have used your EDU mini with any other M0+ chip, say like the SAMD21G. I
have a Seeeduino Xiao but it’s pads are a little off set compared it’s pins. Wondering if it’s single
core with it’s swd interface would work compared too the RP2040 dual core swd… :thinking:

Thank you. Sorry, no SAMD21G. I use several Segger Edu Mini probes with nRF52840 (Nordic, Particle Xenon, micro:bit v2), STM32 (blackpill_f411ce), and RP2040. Out of these, only the J-Link with RP2040 requires a power cycle of the device. It is a bit of an annoyance but I’ll open a bug with Segger, as the issue also occurs with J-Flash Lite.

I have a couple of Adafruit Feather RP2040. You may want to purchase one. These have a space for a standard 10-pin SWD connector plus 8MB SPI Flash and a RGB neopixel. Also, considerably cheaper than an Arduino Nano RP2040, though no Wi-Fi.

I think I’ll be joining you on the Segger forums… :crazy_face:

My thinking was that “Mutil-Drop” and QSPI support has only only been available for the RP2040 for two or three months, would probably take a good few more weeks to correct the firmware for the EDU mini…

The full size J-Link EDU was also available from the same emporium that I got the mini from, and it has had “Multi-Drop” since hw version 10. My one is hw version 11 dated week 9 year 21, same date for my mini v1… Also trolled the segger forums and found no issues on the full size J-Link…

Me been a little impatient decide to get the J-Link EDU (not mini) as well… Turns out the result is the same as the posts above…

I’m a idiot… :crazy_face:

The J-Link EDU is a great purchase and has several advantages over the J-LInk Edu Mini. It’ll be quite useful if you plan to use J-Link with some of the popular MCUs.

btw - I’m opening a support ticket with Segger regarding the need to power cycle a RP2040 in order to flash it with J-Link.

I’ve opened a Support Ticket against Segger J-Link Dev. Hopefully we’ll get the issue reviewed & fixed soon, as the RP2040 J-Link is a profit product for Segger.

One of the bugs (deemed a ‘feature’ request by Segger) I reported against micro:bit v2 J-Link OB will take longer for them to address as the micro:bit OB is low priority & non-profit product.

:+1:

Late this afternoon I registered on the Segger forums, I’m in but the post button is not available yet.
I guess admin approval is still required. I’m a little ticked off that both EDU’s are both not flashing.

See how it goes…

Segger dev are investigating the issue. You should get your Segger forums registration approved within a day or two.

In the mean time, please update the J-Link software to the latest release 7.22b. Also, flash the Segger J-Link Edu Mini probe to version 7.22b using the JLinkConfig utility or with the Edu Mini plugged into a USB port, run JLinkExe and it’ll automatically check for a firmware upgrade.

I have done further tests with both J-Link 7.20 and 7.22b, using both PlatformIO and JFlashLite.

Flashing a RP2040 (Raspberry Pi Pico, PImoroni Tiny2040, Adafruit RP2040) works fine consistently when flashing after a power cycle and after a RP2040 reset.

If a RP2040 is placed into the BOOTSEL Mode (i.e. BOOTSEL pressed & RESET toggled so that the RPI-RP2 gets mounted onto the desktop), flashing fails with the following error.

CoreSight components:
ROMTbl[0] @ E00FF000
ROMTbl[0][0]: E000E000, CID: B105E00D, PID: 000BB008 SCS
ROMTbl[0][1]: E0001000, CID: B105E00D, PID: 000BB00A DWT
ROMTbl[0][2]: E0002000, CID: B105E00D, PID: 000BB00B FPB
Cortex-M0 identified.
PC = 000020F0, CycleCnt = 00000000
R0 = 501008B0, R1 = 00000000, R2 = 00003ECC, R3 = 00000000
R4 = 50100E84, R5 = 00000000, R6 = 00000000, R7 = 50100EAC
R8 = FFFFFFFF, R9 = FFFFFFFF, R10= FFFFFFFF, R11= FFFFFFFF
R12= 50100000
SP(R13)= 50100898, MSP= 50100898, PSP= FFFFFFFC, R14(LR) = 000002B3
XPSR = 61000000: APSR = nZCvq, EPSR = 01000000, IPSR = 000 (NoException)
CFBP = 00000000, CONTROL = 00, FAULTMASK = 00, BASEPRI = 00, PRIMASK = 00
FPU regs: FPU not enabled / not implemented on connected CPU.

Downloading file [.pio/build/pico/firmware.hex]...

****** Error: Timeout while preparing target, RAMCode did not respond in time. (PC = 0xFFFFFFFF, CPSR = 0xFFFFFFFF, LR = 0x01000000)!
Failed to prepare RAMCode using RAM
Error while determining flash info (Bank @ 0x10000000)
Unspecified error -1

Notice that in the BOOTSEL Mode, the PC address is not set correctly in the right Bank.

If you then RESET the RP2040 & try a re-flash, it’ll flash fine. If you’re flashing the same program as what you have on the RP2040, then you’ll get the expected result below.

Downloading file [.pio/build/pico/firmware.hex]...
Comparing flash   [100%] Done.
J-Link: Flash download: Bank 0 @ 0x10000000: Skipped. Contents already match
O.K.

The above behavior is consistent when flashing a RP2040 with both PlatformIO and JFlashLite, using J-Link 7.20 and 7.22b firmwares.

Flashing of a RP2040 after a RESET or a Power Cycle works fine consistently on all the RP2040 boards that I have.

So, the only issue I see is that the RP2040 won’t flash properly if it is in the BOOTSEL Mode. To fix this issue, Segger could force a reset of the RP2040 prior to any flashing.

Something to note when updating J-Link to 7.22b and using PlatformIO.

You’ll need to update the contents of .platformio/packages/tool-jlink with those of J-Link 7.22b.

For example, on macOS (if on MS Windows check location of SEGGER/J-Link), copying

/Applications/SEGGER/JLink to .platformio/packages/tool-jlink

Thx for feed back…

What I didn’t mention above was the first thing both my EDU’s (mini & full size) connected to was the J-Link software package 7.22b that was downloaded a few hours earlier, both firmware’s where update immediately. This was done on a Windows 10 laptop at the office, took them both home and continued my tinkering on an old MxLinux (debian based) laptop. That is where this issue was discovered via PlatformIO, also realized that version 7.20 of J-Link was been used…

My registration on the Segger forums was approved, made a post early afternoon…

I have a spare (unopened) Pi Pico, was thinking of blowing a way the bootloader if possible? This weekend I’ll research that possibility… I’ll wont miss the ability of UF2, the pictool binary method of upload and optimized floating point code contained in the bootrom maybe…

Are you not able to flash your RP2040 using Segger J-link Edu Mini with a software reset?
It should work fine.

I think I mentioned power cycling in my first post…

The need to power cycle the Pi Pico each time tweeks and debugging are done does not work for me, work flow and thinking would be broken…

I haven’t mention debugging yet, as the need to power cycle I think would be a distraction…

OK. In general, a J-Link upload will reset a board and then run the program, whether it is done automatically or manual.

In the case of RP2040, it would be nice to have a J-Link upload without a reset/power cycle. Hopefully Segger will provide a fix for this case.