?!$% $^&# FTDI and %^&$ the %&#D@ FTDI drivers, what is this, 1982?
Everything had been working perfectly all day (I was playing with some palette code) and then the Arduino 1.0.5 IDE just started refusing to upload to the DFRobot Beetle. I tried the “power cycle the Beetle and hit upload before it gets a chance to think” (which had been necessary a couple of times previously), but now I get nothing but “Couldn’t find a Leonardo on the selected port”.
Rebooted, re-installed the FTDI drivers, rebooted, removed the FTDI drivers, rebooted, re-installed, rebooted but nothing works.
Any hints? Can I reset the beetle by shorting the RST pin on the ICSP header to +5V? I’m on MacOS 10.9.3.
I run into serial port problems on my windows machine. For me, closing the Arduino IDE and restarting, seems to alleviate random buggy behavior.
And yes you can reset the beetle the way you described. It seems to be the Achilles’ heel of the beetle: no inbuilt reset button combined with the periodic-need-to-reset the ATmega 32U4 (“Leonardo”'s chip) when it chokes hard.
IMX, Unos and Nanos and other ATmega328 -based boards need reset less often. Tradeoffs.
Also… I didn’t think you needed FTDI drivers for USB-based boards like the Leonardo and clones. But … I could be wrong. As always.
Very, very, very, very occasionally I have had a program go AWOL and trash the boot loader on the target board or the fuse settings.
If you have the equipment to program this, then you should just re-flash the loader and fuses.
Often the protection bits are not set to prevent accidents.
I tried shorting the ICSP RST and +5V and it didn’t seem to do anything. Looks like I’ve somehow managed to trash the entire bootloader like @Adam_Sharp suggests. What a pain.
The plot thickens: after trying to run the same sketch on an Uno and getting similar results, it turns out to be a programming error that was causing the problem—a bung loop index at the root level of my sketch meant I was stomping on, oh, maybe a third of my available memory. Unf*cking that makes it run from the Uno, but I can’t get the virtual port on the Leonardo-style board to come up, as it’s too quick in the startup sequence (before my “sanity delay” in setup()) to get a reset in edgeways.
Is there a cheat way to blank out the program on Beetle without having to re-flash the bootloader?
Long shot:
Make sure there is no sequence of 3 exclamation marks ‘!’ anywhere in your download data.
If the boot loader for your board is derived from the Mega2560 bootloader, then 3 exclamation marks ‘!!!’ will screw up the download.
There is a diagnostic monitor that is triggered when these 3 characters are received within the first 3 seconds. If this is still in the code, it may get triggered. Many bootloaders on processors with enough memory have this either in tact or the remnants sill in the code.
Regarding your erase request: Depending on how you program your Beetle, have a look at the AVRDude manual and see if an erase of some sort that can be sent down. Or you may have to source a cheap programmer to hang on the ICSP port. Worth having in ones tool kit long term. Or make one using your UNO - Plenty of articles on this.
With a hint from the @dfrobot account on Twitter, I’ve got it: I had to short pin 6 (RST) to ground (which is adjacent to pin 6, at the opposite side from the square pad) and I had to hold it for about 1s, then it reset and I could “interrupt” the boot and load new code. Awesome.
Oh hey that’s SUPER to know.
Yep, good to know you have sorted it.
Thanks for the update.
Coming in late, but all AVRs are reset through active low, meaning shorting their reset pin to ground, not VCC.