Adafruit Metro

err, hold on, I found a USB cable with extra shielding that seems to allow the Mac to see it, and flash!

I still don’t understand half of the my past 24 hours experience but it seems it could be all I need… well, ideally I would like to flash via SPI and the command line from my headless Pi but I guess at least I can now take it one step at a time and see if that can be on the card.

Thanks for your help (hopefully for good this time).

and lo and behold it works from the Pi (IDE 1.6.3) as well… I am going to check what voltage the board gets from various ways to power it up, I have the sneaking suspicion my lack luster first few hours with this baby may have to do with that…

no… I don’t think it is power releated… nevermind, I thought it would be useful to post my measurements regardless, for reference:

various voltage measured between GND and pin13 (set HIGH):

  • direct from Mac, with USB cable that works for flashing (extra shielding): 4.9V
  • direct from Mac, with ‘cheap’ USB cable (standard shielding, no luck flashing): 5V
  • direct from Pi, with USB cable that works for flashing (extra shielding): 4.2V
  • direct from Pi, with ‘cheap’ USB cable (standard shielding, no luck flashing): 4.7V
  • official Raspberry Pi foundation USB PSU (5V/2A): 5V
  • Sandstorm branded dual USB charger (5V/4.2A, powering Pi at same time): 5V
  • Universal Regulator 6V/300mA barrel jack: 4.9V
  • Universal Regulator 9V/300mA barrel jack: 4.9V
  • Universal Regulator 12V/300mA barrel jack: 4.9V
  • 5V/2A barrel jack PSU (lower than recommended range): 4.2V
  • 9V NiMH rechargeable battery barrel jack hooked: 4.9V
  • 5V/1A(2600mAh) USB hooked Li-Po battery (Merkury Energy II card): 4.9V

incidentally do NOT go over the 12V recommended range… while looking into my issue I found this guy who got some pretty nasty result at 16V (below the specified limit of 20V):

https://forums.adafruit.com/viewtopic.php?f=19&t=73941&p=375020&hilit=metro#p374908
… well unless you like fireworks of course ;-)

and while I’m at it and it is still fresh in my mind, here’s how to install the Arduino IDE version 1.6.3 on a Raspberry Pi running Raspbian Wheezy.

follow the instructions at:

BUT:

  1. STOP before ‘How to recompile’, as that requires a full distro upgrade, which will likley break your system (without spending significant amount of efforts ironing out the issues)

  2. don’t forget to passify the Jessy repo in sources.list afterwards, again you don’t want to do more upgrades than you have to, especially without realising at a later date

  3. note that the maintainer/package maker advise to use the 1.6.0 release, though for me I had no trouble using his master repo (or at least found workarounds that work for ME)

regarding:

  • You have to start the IDE as superuser (sudo arduino)

I have no trouble, no superuser level required here. Make sure the pi (or whatever your day-to-day user is) is part of the dialout group however.

  • Custom cores cannot be used unless you modify the platform.txt

not relevant for Metro (pretty sure anyhow)

  • Serial ports cannot be opened

this is true, the ‘Ports’ menu seems to be greyed out 9 times out of 10. However, you can simply edit ~/.arduino15/preferences.txt and edit the line starting ‘serial.port=’ with your device address (typically /dev/ttyUSB0).

and that is it. Well, don’t use the ‘Board>Boards Manager’ entry as it wasn’t working in 1.6.3 and will trash your IDE. If you get stuck, purge ~/.arduino15/package_index.json and you should be back in business.

… and indeed, sadly version 1.6.4 is not yet available as a pre-packaged Debian and as a result the Boards Manager, in term of Metro board support there is a fair bit of fiddling to perform if you want the latest Adafruit boards to be listed - but try as G advised above first, that is using a Uno as target board, I will hopefully work, and if not instructions can be found below.

The problem is that Adafruit has not published the Metro board config to their github, so you need to get hold of their ‘board configuration’ master version 1.2.0, which is not only hard to track down, but seems not to be compatible with anything but the Arduino version 1.6.4.

Where there is a will tere is a way however, you can install what is available on their github, and hack in the Metro board config by hand. Sounds complicated, but it isn’t (if you know what you have to do):

  1. Go to: GitHub - adafruit/Adafruit_Arduino_Boards: Configuration and other support files to use Adafruit's boards like Trinket, Pro Trinket, Gemma, Flora, and more with the Arduino IDE 1.6.x and clone the repo or download the Zip file for it.

mkdir ~/Downloads/Adafruit_Metro
cd ~/Downloads/Adafruit_Metro
wget https://github.com/adafruit/Adafruit_Arduino_Boards/archive/master.zip

  1. uncompress and copy the hardware/adafruit folder into your Arduino sketchbook folder:

unzip master.zip
mkdir ~/Arduino/hardware
cp -R ./Adafruit_Arduino_Boards-master/hardware/adafruit
~/Arduino/hardware/adafruit

  1. add the Metro board definition from the most reason json that plugs straight into the latest Arduino IDE:

nano ~/Arduino/hardware/adafruit/avr/boards.txt

##############################################################

metro.name=Adafruit Metro
metro.upload.tool=arduino:avrdude
metro.upload.protocol=arduino
metro.upload.maximum_size=32256
metro.upload.maximum_data_size=2048
metro.upload.speed=115200
metro.bootloader.tool=arduino:avrdude
metro.bootloader.low_fuses=0xFF
metro.bootloader.high_fuses=0xDE
metro.bootloader.extended_fuses=0x05
metro.bootloader.unlock_bits=0x3F
metro.bootloader.lock_bits=0x0F
metro.bootloader.file=arduino:optiboot/optiboot_atmega328.hex
metro.build.mcu=atmega328p
metro.build.f_cpu=16000000L
metro.build.board=AVR_METRO
metro.build.core=arduino:arduino
metro.build.variant=arduino:standard

it does not matter where you place this but be sure not to break an existing board segement, and to have a separator for the new entry as per current file structure.

And that’s it, you should be able to select the Metro in the Arduino IDE and flash it.

For those who want to try to plug the entire Adafruit 1.2 board configuration files it can be downloaded here:

https://adafruit.github.io/arduino-board-index/boards/adafruit-1.2.0.tar.bz2

… but like I said the Arduino IDE didn’t agree with it so I was quite happy to leave it be and wait for the day I can just get version 1.6.4 with automatic board management!

1 Like

nope… I’m still stumped with the SPI upload… got myself a nice USBasp and I can get no further than using the GPIO:

Sketch uses 846 bytes (2%) of program storage space. Maximum is 32,256 bytes.
Global variables use 9 bytes (0%) of dynamic memory, leaving 2,039 bytes for local variables. Maximum is 2,048 bytes.
/usr/bin/avrdude -C/etc/avrdude.conf -v -patmega328p -cusbasp -Pusb -Uflash:w:/tmp/build3567018504877168625.tmp/Blink.cpp.hex:i

avrdude: Version 5.10, compiled on Jun 18 2012 at 12:38:29
Copyright © 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright © 2007-2009 Joerg Wunsch

     System wide configuration file is "/etc/avrdude.conf"
     User configuration file is "/home/pi/.avrduderc"
     User configuration file does not exist or is not a regular file, skipping

     Using Port                    : usb
     Using Programmer              : usbasp
     AVR Part                      : ATMEGA328P
     Chip Erase delay              : 9000 us
     PAGEL                         : PD7
     BS2                           : PC2
     RESET disposition             : dedicated
     RETRY pulse                   : SCK
     serial program mode           : yes
     parallel program mode         : yes
     Timeout                       : 200
     StabDelay                     : 100
     CmdexeDelay                   : 25
     SyncLoops                     : 32
     ByteDelay                     : 0
     PollIndex                     : 3
     PollValue                     : 0x53
     Memory Detail                 :

                              Block Poll               Page                       Polled
       Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
       ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
       eeprom        65     5     4    0 no       1024    4      0  3600  3600 0xff 0xff
       flash         65     6   128    0 yes     32768  128    256  4500  4500 0xff 0xff
       lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
       hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
       efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
       lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
       calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
       signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

     Programmer Type : usbasp
     Description     : USBasp, http://www.fischl.de/usbasp/

avrdude: auto set sck period (because given equals null)
avrdude: error: programm enable: target doesn’t answer. 1
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
anyhow, I’ll put the metro in the car next week… see you at the station!
(never thought I’d ever write something like that without making it up)

RIGHT! I think I finally got to the bottom of the issue… which has nothing to do with the programmer or SPI upload itself but what the Metro has been programmed last with!

basically, to test upload I was using the following looping function, to test uploading as well as have a visual feedback.

void loop() {
digitalWrite(13, HIGH);
}

today I got myself stuck while testing pin D0 after which I could no longer upload using USB. This got me thinking and I’m now convinced that the problem is that the reset pre-upload is being interfered with when the program flashed onto the board is constantly setting a value onto pins required by the upload method.

@gadgetoid, does this sound like a plausible theory?

… anyhow, I’ll know better now to do this and hopefully I won’t ever paint myself in a corner and ‘lock’ both SPI and UART at the same time ;-)

It sounds plausible enough, but I’d always thought reset was… well reset! Uninterrupted, dedicated and designed solely for the purpose of putting the chip into a state it can be communicated with. It would be weird if whatever software was running interfered with that, but I must admit that it really does look like the case.

I wonder how the Metro schematic compares to a basic Arduino Uno, since I’ve never had anything like this kind of weirdness before.

yes… reset should reset, you’d think so. I might try to prove the theory by purposely lock me out of D0 but I’m going to first test SPI upload via the GPIO again, and err make sure the USBasp programmer can get me out of trouble reliably every time :-)

yup… uploading via GPIO worked first time! so, pretty sure that the problem was pin13 locked in the loop.

Strange as you say the auto-reset of the board seems to be temperamental… I wonder if it’s just my board or all Metro.

after going back and forth I’m none the wiser… uploading to this board is just hit and miss, I can’t find any rhyme to it.

What I did notice though is that a fresh burn of the optiboot always leaves D0/RX with a residual 2V, or at least that seems to be residual rather than floating.

As soon as you set that to HIGH then that seems to lead to no end of trouble. Thereafter it seems that the best is either to reflash the bootloader, or press frantically the reset button while uploading.

I have read here http://www.arduino.cc/en/Main/ArduinoBoardUno that you can disable/enable the auto-reset by cutting/linking the RST-EN pads next to the i2C pins… but on mine they appear unconnected, is this the way it should be?

after reading up on the auto-reset feature I’m now convinced that it isn’t working on this board - well, probably more frustratingly for me, it is, occasionally.

Anyhow, I have measured the voltage between GND and the reset pin and the serial uploads do NOT bring the DTR line low. On the other hand I am not sure the time the DTR is brought low is long enough for a voltmeter to register, but either way, auto-reset is not working, well, once every now and then, for no obvious reason. Could be OS related I suppose, or a bug in the IDE 1.6.4 I suppose.

… very frustrated right now…

soldered the RST-EN pads just in case. No difference… as far as I cab tell the only time I can flash via USB reliably (without pressing the RESET) is straight after getting the IDE up and plugging the Metro into the USB port.

… that is on Mac OS X 10.10.3 with Arduino IDE 1.6.4. I guess I could live with that, but it’s kind of personal now and I’ve got to know what the culprit is ;-)

Well, after spending time flashing the board with the Arduino IDE 1.6.4 on a i386 Debian 8 box I can safely say that the DTR line and auto-reset works fine, so it is an OS X fault on that front.

What I can also confirm though is that flashing the blink sketch on D0 i.e RX locks further upload. Seems very strange to me that this should be the case but since this is my first duino I’ll have to give Adafruit the benefit of the doubt that they didn’t botch the job…

Wading through Arduino’s FAQ yielded an answer: apparently pin 0 and 1 need to be disconnected for serial upload. Done and checked. It works.

… so that leaves me with just the OS X auto-reset issue that I can only value as a lesson I’m not likely to forget.

THE END

1 Like

I wish everyone was this relentlessly determined to get to the bottom of problems- it’s frustrating as all hell, but you definitely learn from it. This entire thread reminds me of me any time I get a problem and have a “challenge accepted” moment… it’s more often than not resulted in extremely late nights or early mornings of tinkering.

The OSX issue is odd, I wonder if it’s something to do with the difference between CTS/DTR etc, I’ve definitely got some FTDI serial breakouts that upload fine and successfully reset boards since I used to use them with breadboarduino setups.

1 Like

oh, yeah, definitely not a waste of time… for one I dusted off my trusty eee PC and now have a shiny new Debian box ready to roar, you know, in case one of the other 6 computers in the house would all break at once ;-)

More seriously, I think I’m ready for my next Arduino challenge and already comtemplating dabbling with BLE adapters.

… it could be a driver issue though I even went to the extend of installing the most recent from FTDI.

I have upgraded to IDE 1.6.5 after noticing that the IDE 1.0.5 reliably flashed the Metro (I attached a LCD on it that requires 1.0.5 or earlier) and it works every time now.

So, I can only advice to Mac users to use either the Arduino IDE version 1.0.5, or 1.6.5 (or newer when released) with the Metro!

1.2k views??? Blimey, if only I could go back in time with the hindsight that all/most of my woes were caused by a bug in the Arduino IDE (and many rookie self-inflicted injuries).

… talking of which, 1.6.6 has just been released so expect more reports from the frontline in this necro-thread soon!

I suspect just as many people have the same problem! I know Arduino boards have a history of driving me crazy, which is why I usually program over SPI onto bare Atmegas!

Possibly, to be fair, while convenient to a very small extend, just using the Uno profile in the IDE is the way to go, I’m not convinced Adafruit didn’t shoot themselves in the foot with those ‘board profiles’, even though the process is simpler now.

The Metro is a great product though, I couldn’t be happier with it in retrospect, even though yes, hacking a AVR board from scratch is where the fun is at for me (I need to dust off my ‘HAT’ rig and finish that project off!).