RPI Pico: LED blinks 4 long, 4 short, then again

[rei-vilo]

I am using the Arduino SDK and IDE.

The program compiles and links successfully, but after uploading, the Pico LED starts blinking 4 long (400 ms on, 400 ms off, 4 times) and 4 short (150 ms on, 150 ms off, 4 times) , and again.

Below a logic trace:

Is this a kind of error message like with the Raspberry Pi B board? Where can I find the related documentation?

I first reported the issue at https://www.raspberrypi.org/forums/viewtopic.php?f=144&t=318967, as the blinking LED might have been a message from the hardware, as Inside the RP2040 is a 'permanent ROM' USB UF2 bootloader.

I solved the problem by using another port of Arduino for the RP2040 Pico at https://github.com/earlephilhower/arduino-pico

So the questions are:

• Is the blinking LED a hardware feature from the 'permanent ROM' USB UF2 bootloader or a software feature from arduino /ArduinoCore-mbed?
• Why large projects fail to run with the arduino /ArduinoCore-mbed and succeed with the earlephilhower/arduino-pico?

Thank you!

[facchinm]

Hi @rei-vilo ,
the blinking pattern means that the RTOS has crashed; you can recover a crash dump by connecting an USB to serial port to pins 0/1 (GP0/GP1 -> UART1) . Do you have any example of large projects failing? It could be related to the different way we allocate the ram between stack and heap.

[rei-vilo]

Please find the report from GPIOs 0/1:

++ MbedOS Fault Handler ++

FaultType: HardFault

Context:
R0   : 0000002B
R1   : 10018135
R2   : 202F2F00
R3   : 2000D9DA
R4   : 00000000
R5   : 00000002
R6   : 2000CFE0
R7   : 10018135
R8   : 00000000
R9   : 00000000
R10  : 00000000
R11  : 00000000
R12  : 20000361
SP   : 2000B668
LR   : 10000E39
PC   : 10000E42
xPSR : 01000000
PSP  : 2000B648
MSP  : 2003FFC0
CPUID: 410CC601
Mode : Thread
Priv : Privileged
Stack: PSP

-- MbedOS Fault Handler --



++ MbedOS Error Info ++
Error Status: 0x80FF013D Code: 317 Module: 255
Error Message: Fault exception
Location: 0x10000E42
Error Value: 0x2000CF78
Current Thread: main Id: 0x2000D5B0 Entry: 0x1000948D StackSize: 0x8000 StackMem: 0x200036E8 SP: 0x2000B668 
For more info, visit: https://mbed.com/s/error?error=0x80FF013D&osver=61300&core=0x410CC601&comp=2&ver=110100&tgt=RASPBERRY_PI...

-- MbedOS Error Info --

The link https://armmbed.github.io/mbedos-error/?error=0x80FF013D&osver=61300&core=0x410CC601&comp=2&ver=110100&tgt=RASPBERRY_PI redirects to https://os.mbed.com/docs/mbed-os/v6.14/debug-test/analyzing-mbed-os-crash-dump.html.

The project is an example from the PDLS_EXT3_Basic, which uses some RAM for a frame-buffer, ca. 11248 bytes.

[facchinm]

The trace only makes sense in conjunction with the elf file you are using; take a look at https://github.com/janjongboom/mbed-os-example-fault-handler#running-the-crash-log-parser , enable verbose compilation in the IDE to discover the elf and map file location and try to run it 😉 It should at least give some insight on what is going on but I think it might be memory related indeed (if it only happens if the sketch is big as you stated)

[rei-vilo]

Thank you for the pointers. The Pico still doesn't run the program but no longer sends details about the mbed fault handler. If it happens again, I know the procedure now.

I'm using now the https://github.com/earlephilhower/arduino-pico port.

[Dresch123]

Hi @rei-vilo , the blinking pattern means that the RTOS has crashed; you can recover a crash dump by connecting an USB to serial port to pins 0/1 (GP0/GP1 -> UART1) . Do you have any example of large projects failing? It could be related to the different way we allocate the ram between stack and heap.

I have run into the same problem with my Pico Pi using the Arduino MBed core. I upload a sketch, any sketch, and all I get is a blinking LED (as described) any more. I was doing something similar I guess (allocating a video buffer) when this blinking began. Could you explain what needs to be done once the USB-UART is connected to CP0/GP1? I would really like to be able to use my Pico Pi again.
I tried reloading the UF2 file and that did not help.
Thanks,
Bill

[rei-vilo]

@Dresch123 I let @facchinm answer your question.

In the meantime, feel free to try the https://github.com/earlephilhower/arduino-pico port. It doesn't rely on mbedOS but on the RP2040 SDK.

[Dresch123]

Thank you for the pointers. The Pico still doesn't run the program but no longer sends details about the mbed fault handler. If it happens again, I know the procedure now.

I'm using now the https://github.com/earlephilhower/arduino-pico port.

Yes, I do use Mr. Philhower's core, which is truly impressive.
But I am using TFT_eSPI for high speed video onto LCD displays and the MBed core is strangely faster than the Philhower core for that. If you run the TFT_eSPI example "Bouncing Circles" using the MBed core the frames per second rate is 45, When you run it with the Philhower core, it's 17. I don't know why (something with SPI handling?), but it is very repeatable.

It seems like there should be a way of "unbricking" the Mbed so it can be used again. One bad memory allocation should not destroy a Pico Pi for Mbed...
Thanks for the suggestion.

[Dresch123]

Thank you for the pointers. The Pico still doesn't run the program but no longer sends details about the mbed fault handler. If it happens again, I know the procedure now.
I'm using now the https://github.com/earlephilhower/arduino-pico port.

Yes, I do use Mr. Philhower's core, which is truly impressive. But I am using TFT_eSPI for high speed video onto LCD displays and the MBed core is strangely faster than the Philhower core for that. If you run the TFT_eSPI example "Bouncing Circles" using the MBed core the frames per second rate is 45, When you run it with the Philhower core, it's 17. I don't know why (something with SPI handling?), but it is very repeatable.

It seems like there should be a way of "unbricking" the Mbed so it can be used again. One bad memory allocation should not destroy a Pico Pi for Mbed... Thanks for the suggestion.

Well, I just did the same thing to a brand new Pico Pi, just out of the bag, the blink-of-death after an Arduino Mbed download. I was trying to download the TFT_eSPI example for Mandelbrot for the GC9A01 round LCD. As soon as I downloaded the sketch, the Pico began doing the LED blink pattern and nothing on the LCD screen.

I believe I can now cause the blink-of-death repeatedly. Oh yay.

[facchinm]

@Dresch123 the LED blinking pattern is 99% due to a misconfiguration of SPI pins. Any misconfiguration will cause a runtime error.
I just tested with

#define TFT_MISO        MISO
#define TFT_MOSI        MOSI
#define TFT_SCLK        SCK

in User_Setup.h and there's no crash. For the Pico, default SPI pins are mapped as

#define PIN_SPI_MISO  (4u)
#define PIN_SPI_MOSI  (3u)
#define PIN_SPI_SCK   (2u)

You can choose any of these pins (https://github.com/arduino/mbed-os/blob/rp2040_pr/targets/TARGET_RASPBERRYPI/TARGET_RP2040/PeripheralPins.c#L123-L167) as long as they are bound to the same peripheral (SPI_0 or SPI_1)

For example, this combination should work (in User_Setup.h)

#define TFT_MISO        (24)
#define TFT_MOSI        (11)
#define TFT_SCLK        (14)

[Dresch123]

Thanks! In my user definition I used SPI0, the standard Pico pins defined in TFT_eSPI Pico-ILI9431 user definition. I am away from my bench and computer for a few days, but it was a configuration I have used before and a same wiring, but I will triple check when I get back.
Once it starts blinking, I have not been able to recover, even trying to run programs (like Coremark) that have no SPI definitions in them.
One other thing, the Picos that have been doing this have come from Adafruit. Previously I have used Picos from Microcenter and had not seen this issue. Is it possible that the Adafruit Picos which were purchased later had a later software version or something that made them more prone to this behavior?
I will be back at my bench on Friday if there is anything you would like me to try.
Thank you again. Any suggestions appreciated. I am tired of frying even $4 micros.

[facchinm]

The second issue looks unrelated; Adafruit boards might use a different external flash chip but the outcome would be a totally unresponsive board, not an led blinking pattern.
About the SPI pins, I noticed thet the pins defined in TFT_eSPI lib are
https://github.com/Bodmer/TFT_eSPI/blob/9e64092f58bc4b2458d51ad5bcb0b2e7fdcb6507/User_Setups/Setup60_RP2040_ILI9341.h#L125-L127 , so you may want to change MISO into something different to avoid overriding the default Serial1 interface (however, if you don't use it, it shouldn't hurt).
Let me know if you are able to test this change as soon as you are back 😉

[Dresch123]

The second issue looks unrelated; Adafruit boards might use a different external flash chip but the outcome would be a totally unresponsive board, not an led blinking pattern. About the SPI pins, I noticed thet the pins defined in TFT_eSPI lib are https://github.com/Bodmer/TFT_eSPI/blob/9e64092f58bc4b2458d51ad5bcb0b2e7fdcb6507/User_Setups/Setup60_RP2040_ILI9341.h#L125-L127 , so you may want to change MISO into something different to avoid overriding the default Serial1 interface (however, if you don't use it, it shouldn't hurt). Let me know if you are able to test this change as soon as you are back 😉

Great hint! I have a suspicion... but another question:
Would it matter if I elect not to use an SPUI pin, like MISO? A lot of LCDs don't require the use of MISO and it is sometimes defined as -1 in the definition file to indicate it is not used. Thanks again.

[facchinm]

Not yet, but we merged this PR arduino/mbed-os#19 to allow exatly this use case, and it will be live in upcoming core release