Cannot reprogram my Tinyduino

[stephenh]

I'm new to Arduinos in all forms, though I have a lot of experience with PIC uCs from years of developing embedded systems.
I bought a Tinyduino processor board, SD card shield, GPS shield and USB shield, stacking them up in that order.
I'm programming on a Mac. First off, I found I had to use Arduino 1.6.5 because newer versions did not seem to detect the board when I plugged it in via USB.
My first sketch (perhaps foolishly) was not one of the examples but one that I wrote myself. It was supposed to create a couple of files on the SD card,
then loop forever pinging 'A' to the hardware serial device and expecting a series of 22 bytes in return, which it would then dump to a file on the SD card.
I formatted a 2GB Sandisk SD Card using the recommended formatter.
The sketch uploaded OK and ran, and when I opened the serial monitor, I saw 'A's being streamed to the PC.
After powering it off and putting the SD card in my Mac, I found there were no files on the card.
That was last night and I had to stop at that point.
Today I made some code edits to add diagnostics to the card initialisation, but now when I try to upload the modified sketch, nothing much happens.
On the USB shield, the orange TX light is flickering continuously, but never the RX light.
After about 10-15 minutes the log messages in the editor window show:

Sketch uses 11,488 bytes (37%) of program storage space. Maximum is 30,720 bytes.
Global variables use 1,364 bytes (66%) of dynamic memory, leaving 684 bytes for local variables. Maximum is 2,048 bytes.
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0xe0
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0xe0
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0xe0
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0xe0
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0xe0
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0xe0
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x41
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x41
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x41
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x41
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x41
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x41
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x41
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x41
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x41
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x41


Hmm.... 0x41 == 'A'. So I open up the serial monitor and my original program still seems to be running, pumping out 'A' continuously.

I have also tried building and uploading the SD card info example sketch, but that also fails to upload.

So, does anyone know why the new sketch won't upload?

I have overwritten the original sketch but am happy to share the latest version if it is relevant (some significant edits mean that it's not too similar to the version I did upload though).

Many thanks.

[J Koger]

Hi Stephen,

This Instructable has a pretty good list of things that might cause that error:

http://www.instructables.com/id/A-solution-to-avrdude-stk500getsync-not-in-syn/

When using the Windows version of the Arduino IDE, I've also seen the COM port assigned to the Arduino jump back
and forth from COM3 to COM4 when I reconnect it, for no clear reason. So double-checking the assigned port in the IDE is good.

Best of luck,
John

[stephenh]

Many thanks John.
That link didn't directly solve my issue but it gave me a good hint: I am suspicious that the USB shield is not sending a reset to the processor when trying to start uploading the sketch.
I'll have to get my scope hooked up to it to check this, but I'm thinking that perhaps if my original sketch is chucking too much TX data towards the PC, and isn't being reset, then maybe this is preventing the uploader from establishing comms.
I found that if I unplug the board, wait a minute then plug it back in and quickly try to upload my sketch, it works reliably.
I added a big start-up delay() in my sketch so it doesn't do anything for 5 seconds after power-up, and magically it's become easier to upload sketches.
Annoying, but at least I hadn't somehow bricked the board, which was my main concern.

If I can establish what happens with the reset signal, I'll post the details here...

[hamjudo]

Just a "me too". I independently discovered the same behavior, including the same fix.

[hamjudo]

Now that I think about it. The problem was not in the TinyDuino. I was using CodeBender.cc and 115kbaud on a not particularly fast Chromebook. The text being spewed by the TinyDuino was too much for the browser plugin. So the browser plugin was getting flaky. The browser plugin is either not sending the reset, or the timing was so messed up, that it wasn't useful.

I doubt people see this problem at all with the standard Arduino IDE. Or if they do see it, it only happens on really slows computers. Likewise, the codebender.cc browser plugin can probably handle lower baudrates, and/or running on faster computers.

[Ben Rose]

I thought I responded to this thread- hamjudo, thanks for posting again with some extra information. Too much data back to the serial port can definitely cause timing problems, but it's also definitely something that I'm not quite sure how to solve.

[hamjudo]

Solving the problem is easy once you realize what the problem is. The symptoms are identical to all of the other can't program because the programmer can't talk to the chip errors. All of those errors end up spewing a confusing set of messages about the "stk500...". Popular causes include connections on pins 1 or 2, power supply issues, wrong Arduino choice in the IDE, corrupt bootloader, etc... Figuring out which is the real problem is not easy. Although, this situation would only develop after loading a sketch with Serial.print() calls.

I read a few long threads turned up by googling those error messages. None of them mentioned "talking too much or too fast" as a cause. So I am assuming this issue is limited to codebender.cc, and within codebender.cc, it probably only appears in some configurations. I could get the behavior with the Chrome plugin on a MacBook Air, and a Chromebook, on both a real Uno, and on a TinyDuino. Since I can make it happen with the Uno, it definitely is not your problem.

If your customers have the issue, ask them if they are using Codebender. If so have them try using the standard Arduino IDE instead. If that isn't an option, they can also
 1. unplug the USB cable from their computer.
 2. fix the sketch so there is a delay() in any loop with Serial.print(), or put in a delay at the start of the program.
 3. Saved the fixed sketch.
 4. Hold "shift" and click on the refresh the page icon (the shift key gets Chrome to reload the Codebender plugin. Merely reloading the page is not sufficient.)
 5. Once Codebender finishes reloading, make sure it is the right sketch
 6. Plug in the TinyDuino
 7. Once the USB device shows up, click on "Run on Arduino"

If it doesn't work, try again. If it still doesn't work, try something else. Unfortunately, there are a gazillion errors that cause the same set of messages.

[ChicShaw]

Hi everyone...i am new to this forum and by profession i am a hardware design engineer. As per my experience when using the Windows version of the Arduino IDE, I've also seen the COM port assigned to the Arduino jump back
and forth from COM3 to COM4 when I reconnect it, for no clear reason. So double-checking the assigned port in the IDE is good.

pcb prototypes

[calvinthedestroyer]

If this continues to be a problem then, contact Tinycircuits and see about replacing the USB shield. It could be that you have a bad one. (although, usually when I test a bad one it locks up the USB interface (open pin) or does nothing and get hot (shorted pin).

other than that, make sure everything is set to talk st the same speed?