Large program fails; shows strange LED blink pattern

[jhmaloney]

MicroBlocks is a virtual machine (like MicroPython) that runs on a wide range of 32-bit microcontrollers. We use PlatformIO to build for all of them. MicroBlocks is a fairly large program.

I am porting MicroBlocks to the Raspberry Pi RP2040 chip, the Pico board in particular. It compiles and runs using Arduino IDE 1.8.13 (Mac OS) and Arduino's "Mbed OS RP2040" 2.0.0 board package this community supported package.

The same code compiles and installs with PlatformIO, but the program does not run on the board. The board does not appear as serial port (which it does when the program runs correctly), and the LED blinks in a strange pattern: four long blinks followed by three quick ones. The blink pattern could be an error code of some sort but I haven't been able to find any documentation that will help me decode it.

Here's the platformio.ini file entry I'm using:

[env:pico]
platform = https://github.com/platformio/platform-raspberrypi.git
framework = arduino
board = pico
lib_ignore = WiFi
build_flags = -D ARDUINO_RASPBERRY_PI_PICO

[jhmaloney]

Correction: MicroBlocks does NOT run correctly when built with Arduino's "Mbed OS RP2040" 2.0.0 board package. It does run when built with this community supported package.

So this is Arduino's bug, not a PlatformIO bug.

I'm still curious about the strange LED blink pattern, though. Any idea what it means or where it is documented?

[jhmaloney]

That blink pattern seems to indicate an assertion failure in the mbed initialization sequence. The blink patter is the same as the one shown in the animated GIF in this thread.

It's not clear what assertion is failing, however.

[jhmaloney]

Update: The issue was a misaligned memory access. Our code includes an array of uint8_t that is also accessed by word. Other compilers were word-aligning the start of that array, but not this compiler. Adding "attribute ((aligned (32)))" solved the problem.

I'm fairly sure that the funny blink pattern was coming from mbed's exception handler, but I'm still not sure if the blink pattern encodes the error type. I'd love to know how to get more information about such mbed errors in case I run into any more of them in the future.

[valeros]

Hi @jhmaloney ! Thanks for keeping us posted.

Update: The issue was a misaligned memory access. Our code includes an array of uint8_t that is also accessed by word. Other compilers were word-aligning the start of that array, but not this compiler. Adding "attribute ((aligned (32)))" solved the problem.

Could you please explain what you meant by other compilers? Other versions or something completely different like Clang?

I'm fairly sure that the funny blink pattern was coming from mbed's exception handler, but I'm still not sure if the blink pattern encodes the error type. I'd love to know how to get more information about such mbed errors in case I run into any more of them in the future.

I guess the pattern you saw is so-called Lights of Death, more info here https://os.mbed.com/handbook/Debugging#runtime-errors

Maybe it's a good idea to report the problem to the https://github.com/arduino/ArduinoCore-mbed repository.

[jhmaloney]

Thanks! I'd found the "Lights of Death" page but the blink pattern on the Pico is different what is shown the right-most board on that page (with a single LED). I suspect mbed changed the pattern but hasn't updated the page. The animated gif here shows that new blink pattern.

By other compilers, I mean the compilers used in the all other Arduino PlatformIO frameworks that we use to build MicroBlocks including compilers for nRF5x, SAMD21, ESP8266, and ESP32, Teensy, and more. We've been using PlatformIO to build MicroBlocks for several dozen platforms for a few years now and this is the first compiler that hasn't aligned the start of that uint8_t array on a word boundary, so it took me by surprise. Admittedly, since I hadn't included a "align 32" pragma, the compiler is free to do that.

So, this isn't a compiler bug, it is just different behavior than the compilers I'm used to. (The data structure is accessed as both 32-bit words and as unsigned bytes. It was declared as a uint8_t array because that was convenient and resulted in fewer typecasts.)

In case others get the "lights of death" when porting working code from another microcontroller to the RP2040, you may want to double-check your data structure alignments.

Incidentally, the memory map file showed all my global variables as being at address 0. That probably is a compiler bug.