Sketches build and upload but do not run on Feather M0 - pio3.5.0a

PlatformIO Core
1

I’m using version 3.5.0a of PlatformIO. Sketches I build (Blinky to start) for a couple Adafruit Feather M0 boards upload successfully but do not run. Building the same code in Arduino IDE 1.8.1 loads and runs fine.

I’m using the following in platformio.ini [env:feather]

platform = atmelsam
board = adafruit_feather_m0
framework = arduino

bossac output from each upload (PIO and Arduino IDE) look identical.

Any ideas about how to investigate the problem?

Thanks!

  • Frank
2

I have sparkfun_samd21_mini_usb, the same MCU as adafruit_feather_m0 has. I even tried to flash SparkFun board using adafruit_feather_m0 configuration. All works well.

Please navigate to project folder/.pioenvs/adafruit_feather_m0 and find firmware.bin. Archive it and send to contact@pioplus.com. We will debug your firmware.

Thanks!

Copy of an issue

3

Thanks, I received your firmware and it also does not work for me.

  1. What is your OS?
  2. Please run pio update in PIO IDE Terminal
  3. Please build project again with
pio run - t clean
pio run -v -t upload

All output please share on http://pastebin.com.

4
  1. OS is MacOS Sierra 10.12.6 (16G29)
  2. pio update output: https://pastebin.com/dRgGKukS
  3. pio clean and verbose upload: https://pastebin.com/02qAe4Gc
5

It looks very well!

Could you try to remove “Blink.ino” from src folder and create here main.cpp with the next contents

main.cpp

/*
 * Blink
 * Turns on an LED on for one second,
 * then off for one second, repeatedly.
 */

#include "Arduino.h"

// Set LED_BUILTIN if it is not defined by Arduino framework
// #define LED_BUILTIN 13

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

void loop()
{
  // turn the LED on (HIGH is the voltage level)
  digitalWrite(LED_BUILTIN, HIGH);
  // wait for a second
  delay(200);
  // turn the LED off by making the voltage LOW
  digitalWrite(LED_BUILTIN, LOW);
   // wait for a second
  delay(200);
}

Does it work?

6

Yes. But it has nothing to do with the program.

I figured out the problem. As part of trying to get BlackMagic probe debugging working, a few weeks ago I edited .platformio/packages/framework-arduinosam/variants/feather_m0/linker_scripts/gcc/flash_with_bootloader.ld and I must have changed the Flash origin (without remembering or putting a note to myself about it). When I restored it (+0x2000) PlatformIO upload worked as smoothly as every - no problem.

Thank you so much for looking into my self-imposed problem.

I’m very sorry to have wasted your time with this.

Cheers,

  • Frank
7

:wink:

So, that is very interesting… We would be glad to add BlackMagic configuration for this board. What is wrong with BlackMagic or PlatformIO?

8

When I run with debug_tool=blackmagic and build_flags=-ggdb3 it loads and shows me the first line of Arduino main.cpp. I step past the first lines of initialization to a delay(1) line right before USB initialization. Invariably the debugger breaks in the middle of an ISR and hangs there. Break/continue and the stack continues to be in the same location. I’ll collect more details later.

9

I mean where is problem hidden? In PlatformIO?

10

Sorry to keep you on the edge of your seat - I haven’t had a chance to explore more.

It doesn’t seem like anything in PlatformIO is broken. But specifying the board and debugger should build a binary that runs successfully. I suspect I need to find the right combination of build flags - maybe disable USB or disable the Adafruit Bootloader entirely.

11

We released a big update for Atmel SAM dev/platform. Could you try it out?

Just run pio update.

12
  • Upgraded to 2.6.0 of atmelsam - Sadly, no change.
  • Platformio.ini has
platform = atmelsam
board = adafruit_feather_m0
framework = arduino
build_flags = -ggdb3
debug_tool = blackmagic
  • Starting debug session breaks in Arduino main
int main( void )
{
  init();
  __libc_init_array();
  initVariant();
  delay(1);
  • As soon as it hits the delay(1); it breaks in a signal handler. It never goes beyond that.

image.png620×670 33.7 KB

13

Interesting to note: If I step into the delay() function and step around the loop

  do
  {
    yield() ;
  } while ( _ulTickCount - start < ms ) ;

the signal handler is never called (neither is _ulTickCount ever incremented, so I stay in the loop forever). Only when I Resume does it break in the signal handler.