Forum Index > Projects > LED Pegboard and Matrix Projects
 Meggy Arduino
 |  Printable Version
By: Anonymous: Rafiki () on Monday, December 01 2008 @ 09:16 AM PST (Read 39252 times)  
Anonymous: Rafiki

I have assembled a Meggy, and it works, but I cannot get it to upload from Arduino. I have spent 2 full days trying, and I have done everything in their troubleshooting section, and followed the relavent threads in their forum. Here is the error I get every time:

avrdude: stk500_getsync(): not in sync: resp=0x00
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x51

It is hard to know if Meggy is getting power from the USB port. Shouldn't there be an LED indicating power or something? Is there an easy way to test the physical connections on the TTL? Does it make sense to try a USB5U connection?





       
   
By: Windell (offline) on Monday, December 01 2008 @ 10:21 AM PST  
Windell

Hi Rafiki,
I wish you had posted here earlier rather than trying for two days first!

Meggy Jr does *not* get power from the USB port. It should be powered on independently from the battery (and showing LEDs on the screen -- e.g., yellow scanning LEDs on top) when you attempt to program.

I presume that you are using the FTDI USB-TTL cable. The first thing that you should know is that since your Meggy is working correctly (plays the game and so forth), then the bootloader software (the "Arduino bootloader" ) *is* properly installed on your chip. The chips are programmed in such a way that you can't have the game working without the bootloader software working too. (That's one of the questions you'll see on the forums, I expect.)

Hardware things to check that are specific to Meggy Jr:

1. Take of the handle set. Check the following solder joints *carefully* -- they should look like clean wet and shiny pools of metal connecting the component and the hole on the board: all pins of J2 (the 6-pin right-angle connector), both pins of R4, and both pins of C6. You also need to double-check that pins 1,2, and 3 of your microcontroller U1 are correctly soldered-- those are the three pins closest to the corner by C6.
A bad or intermittent solder connection in any of those places *would* lead to the problem that you are seeing, but *would not* cause any other problems on the board, so these are the most likely places that your problem is lurking.

2. Make sure that the TTL end is connected with the right polarity. I bet you've got this down after two days-- black cable end to the "BLK" side and green end to the "GRN" side.

3. Make sure Meggy has power when you're trying to program. LEDs visible, doing something is a good sign.

Software things to check:

1. Use latest Arduino software (version 0012, right now).

2. Board selected in Arduino menu: Diecimila

3. Correct serial port selected. There's a lot in the forums about selecting the right port, and rightly so-- On Windows, the COM port assigned to the board may be larger than 9, in which case it needs to be re-assigned.

And on your computer....

1. Check to see if you are running any programs that might block access to or independently try to access the USB port (e.g. firewalls, pda sync applications, Processing, etc.)?

2. Try setting upload.verbose to true in your preferences.txt file - make sure to edit the file when the Arduino software is not running. Then try uploading again and post the messages you get.
This preferences file is found in this folder:

* /Users/<USERNAME>/Library/Arduino/preferences.txt (Mac)
* c:\Documents and Settings\<USERNAME>\Application Data\Arduino\preferences.txt (Windows)
* ~/.arduino/preferences.txt (Linux)

3. Try re-installing FTDI USB driver

4. *If* you can (and I'm not saying this is the case!), you might also try installing the software and programming from a different computer to see if there's something unexpectedly interfering with your own setup.

Good luck!
-Windell


Windell H. Oskay
drwho(at)evilmadscientist.com
http://www.evilmadscientist.com/

Forum Evil Scientist
Evil Scientist

Status: offline

Registered: 06/15/06
Posts: 1932
Sunnyvale, CA

Profile Email Website  
   
By: Anonymous: Rafiki () on Monday, December 01 2008 @ 11:51 AM PST  
Anonymous: Rafiki

Windell,

Thanks for the thoughtful reply.

It worked! It worked! It worked! (you are a geeenious)

I had done most of what you mentioned, but I must admit that I was mostly trying it with the power off, since most of what I read online strongly implied that the board would get power from the USB port. You might want to add that to the instructions for those of us who ain't too bright.

Two issues during construction:

1) I put the frigging 6 pin connector for the TTL upsidedown (long pins through the board). I know that nobody has ever done this, and I know that there is a picture, but it didn't occur to me that there were two ways until I started on the 3 pin jumper, and of course then it was too late. I bought another header, but in the course of removing the other one the metal appears to have come off the board holes and solder did not flow onto the board and get shiny like the rest of the connections. The more I tried to fix it the worse it got. I checked the schematic and used my multimeter to confirm the connections, but with the problems I had uploading I became suspicious that I'd fragged something in the process. I'm so idiot. Maybe a note to other idiots will save somebody the heartache.

2) The 1200uf capacitor does not fit under the LED panel, so the damn thing tilts. Sure, this is no huge deal, but it bugs the crap out of me. I looked for a sleeker capacitor but could not find one. If I had it to do over again (and I might) I would either move the capacitor (if possible) or put a spacer on the other side of the panel so that the whole thing is level.

3) Bonus Issue - the velcro does a shitty job of holding the battery box, but a thin strip of purple duct tape is groovey.

These are very cool. How many do you think you will sell? I am thinking about getting another one for my son now that I've got it up and running. First, however, I'm going to try my hand at programming. I've had a lot of experience with VB, but virtually none with C. How hard can it be?

Thanks,
Mark





       
   
By: Windell (offline) on Monday, December 01 2008 @ 12:17 PM PST  
Windell

It worked! It worked!

I'm very glad to hear that!

[...] most of what I read online strongly implied that the board would get power from the USB port.

Running off of USB power was never part of the design (peak power requirements are too high), so we certainly tried to avoid any indication that it could be powered by USB-- is there a specific thing that seems (to you) to imply it? Please let us know and we'll change it for clarity. We'll also add a note in future instruction sets.

I put the frigging 6 pin connector for the TTL upsidedown

I'm not sure what we can do to make that one more clear. There's a picture right next to the instruction, and a drawing of the part on the circuit board.

The 1200uf capacitor does not fit under the LED panel, so the damn thing tilts.

It would be nice if the cap were much smaller, but the display can definitely be made to sit flat. One trick is to solder one corner pin first, and then to make sure the display is sitting flat before proceeding. You can probably somewhat straighten out your display in place by loosening up the solder joints of the display while firmly pulling the display in the right direction.

Bonus Issue - the velcro does a shitty job of holding the battery box

I'm afraid that I'll have to disagree with this one. That particular velcro has almost dangerously strong adhesive on it, and if you've trimmed flat the leads on the back side where the loop side sticks, it sticks extremely well. Our battery boxes (after a lot of testing, programming, and play time) have not gone anywhere at all.

How many do you think you will sell?

We'll have several hundred of them out there by the end of the year; hard to say much further in the future.

I've had a lot of experience with VB, but virtually none with C. How hard can it be?

Not very. Smile
Since you already understand how syntax works-- in general-- you can look at the code of some of our example programs and start to make small mods and still get it to run. Once you can do that, you'll start to see how bigger changes work, and then pretty soon your programs will be more complicated than ours. We'll also have a new Meggy Jr programming guide coming out soon.


Windell H. Oskay
drwho(at)evilmadscientist.com
http://www.evilmadscientist.com/

Forum Evil Scientist
Evil Scientist

Status: offline

Registered: 06/15/06
Posts: 1932
Sunnyvale, CA

Profile Email Website  
   
By: Anonymous: Rafiki () on Tuesday, December 02 2008 @ 07:23 AM PST  
Anonymous: Rafiki

Every time I upload I have to first unplug the USB cable from the computer and plug it back in; otherwise, I get the original error message. Turning Meggy off and on, or hitting the reset button does not do it. Strange.





       
   
By: Windell (offline) on Tuesday, December 02 2008 @ 10:05 AM PST  
Windell

Every time I upload I have to first unplug the USB cable from the computer and plug it back in;

Okay, that's very strange. Not sure that I know anything that will fix it... but maybe you can asay what OS/version are you using, and what computer type and model?


Windell H. Oskay
drwho(at)evilmadscientist.com
http://www.evilmadscientist.com/

Forum Evil Scientist
Evil Scientist

Status: offline

Registered: 06/15/06
Posts: 1932
Sunnyvale, CA

Profile Email Website  
   
By: Anonymous: Rafiki () on Tuesday, December 02 2008 @ 03:19 PM PST  
Anonymous: Rafiki

This is undoubtedly the reason for many of the problems I had initially (plus not turning the damn thing on).

Here are the details:

Windows Vista Home Premium – up to date with all available service packs and upgrades.
USB serial port drivers up to date and functioning properly
Computer is a Compact Presario – Hewlett Packard
Model: SR5023WM
Processor: AMD Athlon 64 3800+ 2.4 GHz
System Type: 32-bit operating system
RAM: 894MB
Arduino 0012 Alpha

When I start from a fresh boot, turn on Meggy, plug in the USB, and load Arduino (requires run.bat, won’t load arduino.exe) I get the following error (verbose = true):


avrdude: Version 5.4-arduino, compiled on Oct 11 2007 at 19:12:32
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/

System wide configuration file is "C:\Tools\arduino-0012\hardware/tools/avr/etc/avrdude.conf"

Using Port : \\.\COM3
Using Programmer : stk500v1
Overriding Baud Rate : 19200
avrdude: ser_open(): setting dtr
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: Recv:
avrdude: stk500_getsync(): not in sync: resp=0x00
avrdude: Send: Q [51] [20]
avrdude: Recv:
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x51

avrdude done. Thank you.


Binary sketch size: 10562 bytes (of a 14336 byte maximum)
C:\Tools\arduino-0012\hardware/tools/avr/bin/avrdude -CC:\Tools\arduino-0012\hardware/tools/avr/etc/avrdude.conf -v -v -v -v -pm168 -cstk500v1 -P\\.\COM3 -b19200 -D -Uflash:w:C:\Tools\arduino-0012\hardware\libraries\MeggyJr\examples\MeggyJr_Attack\applet\MeggyJr_Attack.hex:i
When I unplug the USB and immediately plug it back in, I get a successful upload with the following info:

avrdude: Version 5.4-arduino, compiled on Oct 11 2007 at 19:12:32
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/

System wide configuration file is "C:\Tools\arduino-0012\hardware/tools/avr/etc/avrdude.conf"

Using Port : \\.\COM3
Using Programmer : stk500v1
Overriding Baud Rate : 19200
avrdude: ser_open(): setting dtr
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: Recv:
avrdude: Recv:
AVR Part : ATMEGA168
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 512 4 0 3600 3600 0xff 0xff
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
flash 65 6 128 0 yes 16384 128 128 4500 4500 0xff 0xff
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
lfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
hfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
efuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
lock 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00

Programmer Type : STK500
Description : Atmel STK500 Version 1.x firmware
avrdude: Send: A [41] . [80] [20]
avrdude: Recv:
avrdude: Recv:
avrdude: Recv:
avrdude: Send: A [41] . [81] [20]
avrdude: Recv:

…Reams and reams of send/recv messages.
Then at the end, the pleasing message:
avrdude done. Thank you.

If I immediately hit upload again, I go through the same process once more. Each upload requires a USB reset, which is a pain in the ass, but has become unconscious part of my routine, like a nervous tick.





       
   
By: Windell (offline) on Tuesday, December 02 2008 @ 03:36 PM PST  
Windell

Well... I don't see anything obviously wrong with that setup, which leaves me even more puzzled. You might try going to the FTDI site and re-installing the driver for the TTL-232R if you haven't already; that has been known to fix some problems.

Another thing to try might be communicating over the serial port to the Meggy while it's hooked up to the computer. It might be interesting to see if the problem is that the serial link is "dead" or if it's not resetting properly, or something else entirely.


Windell H. Oskay
drwho(at)evilmadscientist.com
http://www.evilmadscientist.com/

Forum Evil Scientist
Evil Scientist

Status: offline

Registered: 06/15/06
Posts: 1932
Sunnyvale, CA

Profile Email Website  
   
By: Anonymous: Rafiki () on Friday, December 05 2008 @ 01:26 PM PST  
Anonymous: Rafiki

I set up the identical arduino/Meggy directory on a different computer (in a different city, actually) and the exact same behavior occurs. To upload I must first unplug and then re-plug the USB. Curiouser and curiouser.





       
   
By: Anonymous: Rafiki () on Monday, December 08 2008 @ 05:03 PM PST  
Anonymous: Rafiki

Now I'm getting extremely eratic behavior. In addition to having to unplug the USB, now I'm getting frequent upload errors with programs that I know work, but even when the upload is successful, the program might not run properly on meggy. Here is an upload error message I'm getting with increased frequency:

avrdude: stk500_paged_write(): (a) protocol error, expect=0x14, resp=0x64
avrdude: failed to write flash memory, rc=-4
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x51

I wonder if there is something wrong with my cable, board or chip.





       
   
By: Windell (offline) on Monday, December 08 2008 @ 05:23 PM PST  
Windell

A problem with the chip itself is *very* unlikely. When the chip goes, it *goes.* A cable problem is a likely cause of intermittent problems-- check to make sure that the pins all seem to be firmly pin place. It looks like your error code reflects the programs not running properly-- the verification fails, meaning that the right code wasn't written to memory.
Also check:
See if you might have a bad solder joint somewhere near the TTL port-- a flaky solder joint could certainly cause this.
Make sure that the covers are on. Touching the pins while programming can cause issues.
Make sure that your batteries are still good. Gradually changing LED color is one sign that your batteries are done.

-Windell


Windell H. Oskay
drwho(at)evilmadscientist.com
http://www.evilmadscientist.com/

Forum Evil Scientist
Evil Scientist

Status: offline

Registered: 06/15/06
Posts: 1932
Sunnyvale, CA

Profile Email Website  
   
By: steveORsteven (offline) on Friday, December 12 2008 @ 08:29 PM PST  
steveORsteven

Hi. Here is some of the behaviour I'm getting tonight on WinXP.
Yes, I too must unplug the FTDI cable after each programming attempt. Otherwise get these stk500 errors. I have the latest driver from their website. Secondly, but once programming did begin (when the matrix goes blank) it would kick right back into the currently loaded program after about 1 second. Nothing was programmed. I was using batteries, which are alkaline and used for only 1 to 2 hours, so I over switched to external adapter and now the programming works fine. (but still need to unplug cable each time)
Steve


Forum Henchperson
Henchperson

Status: offline

Registered: 12/12/08
Posts: 16
Brooklyn, NY

Profile Email Website  
   
By: steveORsteven (offline) on Friday, December 12 2008 @ 08:49 PM PST  
steveORsteven

It also appears to help to have mjr turned ON before cable is plugged into usb port.


Forum Henchperson
Henchperson

Status: offline

Registered: 12/12/08
Posts: 16
Brooklyn, NY

Profile Email Website  
   
By: Windell (offline) on Saturday, December 13 2008 @ 11:17 AM PST  
Windell

About having to unplug after every upload on Windows.... I looked around and this bug is common to other Arduino compatible devices that use the FTDI USB-TTL cable.

Try adjusting your port settings (Windows only)
Device Manager - Comm Ports - USB Serial Port -
Port Settings - Advanced button - Set RTS On Close

This solution that was described for the RBBB from Modern Device, http://moderndevice.com/RBBB.shtml

Does this fix it?


Windell H. Oskay
drwho(at)evilmadscientist.com
http://www.evilmadscientist.com/

Forum Evil Scientist
Evil Scientist

Status: offline

Registered: 06/15/06
Posts: 1932
Sunnyvale, CA

Profile Email Website  
   
By: Rafiki (offline) on Sunday, December 14 2008 @ 07:43 AM PST  
Rafiki

You be geeeenius.

That seems to have solved the problem, which I assumed was due to an assembly oops. In fact, I just re-soldered the TTL header for the third time. This should make my life considerably less complicated. I was wearing down the USB port pretty good, and Since this behavior happens on all three different machines I've tried - all running a different flavor of Windows - I am going to guess that it will be ubiquitous for Windows users.


Forum Apprentice
Apprentice

Status: offline

Registered: 12/09/08
Posts: 14
Bloomington, IN USA

Profile Email Website  
   



 All times are PDT. The time is now 08:32 PM.
Normal Topic Normal Topic
Locked Topic Locked Topic
Sticky Topic Sticky Topic
New Post New Post
Sticky Topic W/ New Post Sticky Topic W/ New Post
Locked Topic W/ New Post Locked Topic W/ New Post
View Anonymous Posts 
Able to Post 
Filtered HTML Allowed 
Censored Content 

Evil Mad Scientist Forum Archives — Read only!

Please visit our new forums for new discussions.


DIY Hardware for Electronic Art


The Original Egg-Bot Kit


Octolively
Interactive LED kits


Meggy Jr RGB
LED matrix game
development kit.


Business-card sized
AVR target boards


Peggy 2
LED Pegboard kits

My Account






Lost your password?