Platformio-core: Please add support for some SAMD21 boards:

[malachib]

• Sparkfun SAMD dev / mini
• Adafruit M0 feather series (I expect all of them would work as one single feather m0 target)

I've been using the zeroUSB profile to (very effectively!) program my SAMD with platformio but technically it's the wrong PID and might eventually cause issues. Have not tried my adafruit yet

[thirstyfish]

+1

Have you managed to get the Adafruit Feather m0 Wifi board working?
( I'm referring to this one: https://learn.adafruit.com/adafruit-feather-m0-wifi-atwinc1500?view=all )
I tried to get it to work with the zeroUSB config, but it was missing analog PINs I'm using, so I tried to hack it together by copying the relevant pieces over from
_~/Library/Arduino15/packages/adafruit/hardware/samd_ (e.g. the variant files), but then I had some other issues unfortunately trying to compile the Adafruit-GFX-Library:

.pioenvs/zeroUSB/Adafruit-GFX-Library/fontconvert/fontconvert.c:23:22: fatal error: ft2build.h: No such file or directory

[malachib]

Haven't tried the Adafruit yet (mine is the coveted BLE version) but I expect similar results as yours

EDIT: I tried this morning and even with blinky I am unable to get a successful upload to the M0. At best, red light goes into "breathing" mode (presumably upload/bootloader ready mode)

EDIT2: After some hacking about I discovered something interesting. When "platformio run -t upload" is run, the following command line is generated:

"/Users/Malachi/.platformio/packages/tool-bossac/bossac" --info --port cu.usbmodem1411 --erase --write --verify --reset --debug .pioenvs/adafruit_m0/firmware.bin

resulting in:

No device found on cu.usbmodem1411 scons: *** [upload] Error 1

but, if one copies and pastes that exact same bossac command line into terminal, upload works A-OK.

This round of testing done on Mac OS X 10.11

[aethaniel]

@ivankravets, this ticket should not be labelled vendor:atmel :wink: as the issue seems to be in OSX, maybe around user rights to read/write on a system peripheral (cu.usbmodem1411 in this case).

The boards listed here are compatible with Arduino Zero, thus the label vendor:arduino or arch:sam should be added instead

[malachib]

I believe I've discovered what aggravates this problem. I observe similar behaviors on my debian machine.

I theorize that some component of the build chain attempts to invoke bossac with something like "/dev/cu.usbmodem1411" and fails because it must be formatted only as "cu.usbmodem1411".

[ivankravets]

@malachib what do you see for pio serialports list?

[malachib]

For the record, pio run -t upload frequently works on my debian machine (haven't been using it on the mac lately). Once in a while it fails and seems to leave it in a state which I must run manual bossac to recover. Debian results of pio serialport list

While the device is out of programming mode, we see:

/dev/ttyS0
----------
Hardware ID: PNP0501
Description: ttyS0

/dev/ttyACM0
------------
Hardware ID: USB VID:PID=2341:804D LOCATION=2-2.1
Description: Arduino Zero

While in programming mode (put there on purpose, not accidentally reached), we see:

/dev/ttyS0
----------
Hardware ID: PNP0501
Description: ttyS0

/dev/ttyACM0
------------
Hardware ID: USB VID:PID=1B4F:0D21 LOCATION=2-2.1
Description: ttyACM0

[ivankravets]

PlatformIO uses pio serialport list results before upload. I can't imagine how you receive cu.usbmodem1411 instead /dev/cu.usbmodem1411... 😢

[malachib]

I'm thinking the opposite is happening. BOSSAC expects no /dev/ prefix and maybe one is present sometimes? Just a theory only

[ivankravets]

BOSSAC expects no /dev/ prefix

@valeros is it true?

[malachib]

Another tidbit - on debian today. I'm discovering sparkfun board seems to need up to a 20s ish delay after entering program mode before it will accept programming. Also, today pio isn't able to program it at all - the "state" described above (7d ago) seems to be program mode - which pio always succeeds at getting the device into.

[tabchas]

Also having problems uploading to Adafruit Feather. Any ideas of a fix? This is only reason I'm still using the regular Arduino IDE.

[ivankravets]

@tabchas , @malachib , looks like the issue with uploading has been fixed today. Could you try http://docs.platformio.org/en/latest/installation.html#development-version ?

[malachib]

Willdo - thanks Ivan!

[tabchas]

@malachib Does it work for you?

I still get an error during upload.

[malachib]

I am trying on my Mac right now and it's behaving very well. However:

• I'm not sure if I'm running the dev version of platformio here (@ivankravets how do I check?)
• Haven't tested on the Mac in a while. So maybe a false positive. Gonna try my linux box shortly

Side note: almost blew up my SAMD today. It still works, so the hunt for where that smoke was coming from continues =)

[ivankravets]

@tabchas what is your OS? I've pushed new updates to development version (2.9.3.dev0). Could you try new build? See instructions http://docs.platformio.org/en/latest/installation.html#development-version

[ivankravets]

@malachib

I'm not sure if I'm running the dev version of platformio here

Do you use PlatformIO IDE? Check CLI version via Menu: PlatformIO > Home screen.

[malachib]

OK:

Mac: platformio 2.9.2
Debian: platformio 2.9.3.dev0

Unfortunately Debian still not playing nice. Mac passes basic tests (cool!). Following is for Debian only:

Scenario A

If I do pio run -t upload it will:

a) promptly put device into program mode
b) error out with:

No device found on ttyACM0
scons: *** [upload] Error 1

at which point pio run -t upload will only generate

Set binary mode
No device found on ttyACM0
Send auto-baud
Set binary mode
scons: *** [upload] Error 1

so I must proceed to c) run manual bossac for successful upload (no sudo needed)

---

Scenario B

If I do sudo pio run -t upload it sometimes manages to upload successfully, after trying a few times getting errors like:

Set binary mode
Send auto-baud
Set binary mode
readWord(addr=0)=0x200023a0
readWord(addr=0xe000ed00)=0x410cc601
readWord(addr=0x41002018)=0x10010205
version()=v1.1 [SparkFun:XYZ] Sep 24 2015 16:50:58
chipId=0x10010005
Connected at 115200 baud
readWord(addr=0)=0x200023a0
readWord(addr=0xe000ed00)=0x410cc601
readWord(addr=0x41002018)=0x10010205
Atmel SMART device 0x10010005 found
write(addr=0x20004000,size=0x34)

SAM-BA operation failed

Sometimes not, in which case I have to run my manual bossac many many times to coax it back into working again EDIT: it seems actually I must reset the device first (when I does, it stays in program mode)

[tabchas]

Upload works! I selected "Arduino Zero (USB Native Port)" and am using the Adafruit Feather Bluefruit M0 board.

Thanks guys!

[ivankravets]

@tabchas what is your OS?

[tabchas]

@ivankravets I am on OSX 10.11.5

[ivankravets]

@tabchas thanks a lot for the report. Yes, the latest PlatformIO 2.9.4 should work very well on the Mac and Windows.

We have the one issue with Linux - udev rules. User have to specify valid PID/VID udev rules for the SAM-BA based board. The one rule should be specified for the default Native USB port and other for the PROGRAM/BOOTLOADER serial port.

[valeros]

Added support for several SAMD21 based boards:

adafruit_feather_m0_usb
sparkfun_samd21_dev_usb
sparkfun_samd21_mini_usb

Please install PlatformIO dev version and update framework-arduinosam package via platformio update
Special thanks to @malachib for providing a test board!

[ivankravets]

@malachib does it work for you?

[malachib]

Using pio version 2.10.4.dev2 and the newest udev rules as of today.

Debian results are very positive. Initial attempt at pio run -t upload yields a fully successful upload! Subsequent attempts fail with:

scons: *** [upload] could not open port /dev/ttyACM0: [Errno 16] Device or resource busy: '/dev/ttyACM0'

which can be overcome either by:

1. running sudo pio run -t upload
2. waiting a certain amount of time (seems to be over a minute)

FYI no. 1 I have additional udev 99-mal.rules file on my Debian machine cuz it seemed the pio one was missing the vid/pid which my sparkfun wanted. Can't say conclusively how helpful they are or if I did it right, but they were in place for my Jun 3rd results and today's results:

ATTRS{idVendor}=="1b4f", ATTRS{idProduct}=="0d21", ENV{ID_MM_DEVICE_IGNORE}="1"
ATTRS{idVendor}=="1b4f", ATTRS{idProduct}=="0d21", ENV{MTP_NO_PROBE}="1"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1b4f", ATTRS{idProduct}=="0d21", MODE:="0666"
KERNEL=="ttyACM*", ATTRS{idVendor}=="1b4f", ATTRS{idProduct}=="0d21", MODE:="0666"

FYI no. 2 I also tried this on an Ubuntu 16.04 box using the versions described on the first line. Doesn't have my "special" 99-mal.rules.

The results are similar to my Jun 3rd post _except_ that sudo pio run -t upload does seem to consistently upload to the device after a few tries.

[ivankravets]

@malachib do you use this board = sparkfun_samd21_dev_usb? Check that 2 USB devices (in boot mode and without) are listed in udev rules

[malachib]

I am indeed using board = sparkfun_samd21_dev_usb

EDIT:

Looks like VID:PID for this board is as follows :

run mode = 1B4F:8D21
program mode = 1B4F:0D21

I'll try adding the other to my udev rules and share results

[ivankravets]

@malachib do you have any news?

[valeros]

Hi @malachib! Does upload process work well in Arduino IDE?
Probably this issue isn't linked with your udev rules. I've found some information about this problem on the SparkFun website (at the bottom of the page) and looks like it's a known issue with their board.

[ivankravets]

@malachib I propose to open a new issue with detailed description about your problem. I'm going to make release with the other boards that described here.

[malachib]

Sorry been out of town! I'll try out Arduino IDE and get back to you