Forum Index > Projects > LED Pegboard and Matrix Projects
 Can't program Meggy on Mac
 |  Printable Version
By: Windell (offline) on Wednesday, July 08 2009 @ 05:59 PM PDT  
Windell

Fantastic!
I'm glad that this is finally put to rest. And, I'm always glad when there's a logical explanation in the end. Big Grin


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: Brian () on Sunday, January 17 2010 @ 11:52 AM PST  
Anonymous: Brian

I had this same problem, but it came up out of the blue after we'd been successfully uploading our own programs for about a week, so I didn't suspect the solder joints. (I didn't check them, either...)

I could upload from another computer no problem.

On the troublesome one, I changed the target board from "Duemilanove or Nano w/ ATMega 328" to "Arduino Pro or Pro Mini (3.3v 8MHz) w/ ATMega 328" and it uploaded fine. Changed it back, and it's working again as it was before.

Wierd.

Troublesome platform was an iBook G4. Happy one is an intel iMac. Arduino 0017 on both. I'm uploading via the USB-TTL cable I bought from EMSL along with the Meggy.

Just posting in case this info is helpful to someone.

--
Brian





       
   
By: bbk (offline) on Sunday, January 31 2010 @ 08:58 AM PST  
bbk

That was me, Anonymous Brian above. The problem's back. I can't upload to Meggy anymore from either computer.

I checked my board, my 10K R4 is correct. All solder joints look good to me. More to the point, it was working fine for a couple weeks, with quite a few programs uploaded as my son and I learn how to program this. I'm using the USB-TTL cable I bought with the Meggy from EMSL, and it's plugged in the right way on the Meggy, and to a USB port directly on the iMac.

I'm running from the battery pack, measuring 4.06v on the "batt in" contacts while powered on, and 4.13 across the batteries themselves with the Meggy off.

What else might cause it to stop responding? What should I be looking at?

I set upload.verbose=true in my Arduino prefs file and I get this:

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

[snip]

Using Port : /dev/tty.usbserial-FTE562Y1
Using Programmer : stk500v1
Overriding Baud Rate : 57600
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: Send: Q [51] [20]
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding



Forum Apprentice
Apprentice

Status: offline

Registered: 01/12/08
Posts: 10

Profile Email    
   
By: Windell (offline) on Sunday, January 31 2010 @ 04:36 PM PST  
Windell

The fact that it was or wasn't working earlier with seemingly irrelevant changes is suspicious-- suggests that something flaky is in your setup.

Check to make sure that you're not using any other serial devices or programs that access the serial ports that could be causing issues.

4.13 V is fairly low, under 1.4 V per cell. If the games still play, it should be okay for programming though.

>avrdude: stk500_recv(): programmer is not responding

You'll get this message in a variety of circumstances, including the following:
- Cable is not plugged into the Meggy Jr RGB
- Wrong board selected
- Wrong port selected (although yours looks correct)
- Damaged cable; inspect the end carefully to see if any of the wires have broken.

One thing to check immediately is to see whether the Meggy Jr resets when you try to program. Resetting is necessary for programming, and it should go dark for about 1.5 s after switching on or hitting the reset button. If it does not reset, then there's something wrong with the cable, the reset hardware (the capacitor and resistor), or with the software.


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: bbk (offline) on Monday, February 01 2010 @ 06:12 PM PST  
bbk

It's working again. I didn't change anything. Hm. Maybe just the reboot did it, if the port was tied up with something.

Thanks for the troubleshooting list, though. Good to have a starting place in case it comes up again.

I can't wait to get started programming again!


Forum Apprentice
Apprentice

Status: offline

Registered: 01/12/08
Posts: 10

Profile Email    
   
By: bbk (offline) on Tuesday, February 02 2010 @ 06:35 PM PST  
bbk

OK, something is broken, and I think it's in the Meggy. It worked for a few test uploads (running cherry tomato 3) and then stopped again. I can't upload from the iMac, or from the iBook. I even tried installing Arduino and the Meggy, Jr libs on two different XP machines, and I can't upload from them, either. I've got Arduino 18 installed now. So, four different computers all fail to upload to one Meggy. Right now, the Meggy is running the last small test program we were able to upload to it.

The Macs tell me the same as in the previous message. The Meggy display does go blank for that second-and-a-half you mentioned, so it looks like it *is* resetting. The reset button on the Meggy causes that same behavior.

Is there a limit to the number of times I can upload to it? We'd probably gone through a couple dozen uploads before it started doing this.

I'm looking for ideas. I'm comfortable with software, but the hardware world is new to me.


Windows tells me this (I verified it really is COM3 in Device Manager):

Binary sketch size: 1796 bytes (of a 30720 byte maximum)
C:\Documents and Settings\Administrator\Desktop\arduino-0018\hardware/tools/avr/bin/avrdude -CC:\Documents and Settings\Administrator\Desktop\arduino-0018\hardware/tools/avr/etc/avrdude.conf -v -v -v -v -patmega328p -cstk500v1 -P\\.\COM3 -b57600 -D -Uflash:w:C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\build79376779072002953.tmp\sketch_feb02a.cpp.hex:i


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:\Documents and Settings\Administrator\Desktop\arduino-0018\hardware/tools/avr/etc/avrdude.conf"

Using Port : \\.\COM3
Using Programmer : stk500v1
Overriding Baud Rate : 57600
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.


Forum Apprentice
Apprentice

Status: offline

Registered: 01/12/08
Posts: 10

Profile Email    
   
By: Windell (offline) on Tuesday, February 02 2010 @ 07:48 PM PST  
Windell

>Is there a limit to the number of times I can upload to it?

Yes... it's only specified for 10,000 cycles. I'm going to guess that you're not quite there yet.

If the Meggy consistently resets, that's most of the hard part. There's a common problem on windows boxes that causes this to not work unless you unplug it every time before programming (fixed by the "set rts on close" setting).

Four lines are needed for programming: The reset signal, ground, TX (transmit) and RX (receive). Since you're getting reset, that means that (1) the cable is plugged in the right way and (2) the reset and ground signals are getting there. That leaves just the TX and RX signals. From what you've described, you've got a flaky connection on one of those two lines, either in your cable, in the connector, or at the chip.

First, check the cable end. Make sure that none of the wires looks loose or frayed. Make sure that the exposed gold tabs (midway through one face of the cable end) are all present and look reasonably similar.

Next, take off the Meggy handle, and inspect connector J2. The two relevant pins are in the right half of the connector (as viewed normally), not the end pin, but the two next to it. You'll probably want to resolder those two pins of the connector.

Next, inspect the relevant pins of the chip. The two that you care about are in the analogous location on the chip: they are the two in the upper right hand corner closest to (but not including) the end pin. Inspect them carefully, and probably resolder those two pins.

Also, make sure that there isn't any junk solder, stray bits of metal, or other foreign debris on the upper or lower side of the board, in that general area.

One other fix that sometimes works-- for reasons of flakiness on the PC side of things --is to push the rest button about halfway through the second-and-a-half period.

If you can occasionally get uploading to cooperate, you might also consider uploading one of the serial programs, such as MeggyJr_RemoteDraw. Using that with the processing program that communicates with the Meggy might be able to help you narrow down whether the problem is on the TX or RX side of things.


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: bbk (offline) on Wednesday, February 03 2010 @ 10:30 AM PST  
bbk

Wow. Thanks for all the detail!

I just tried all that on my lunch break, and didn't find anything fishy.

Continuity is confirmed from each wire (w/ sewing pin thru the insulation) to each contact in the USB-TTL connector, and again from the connector to the contact on the Meggy by plugging it in upside down and probing with continuity tester. (right side up, I can't get to the contacts in the connector).

I touched up all the solder joints you mentioned, and then some - all 6 from the cable connection, and the whole one side of the ATMega closer to where the cable connects. Still get the same behavior when I try to upload a program.

I posted some photos here:

http://www.flickr.com/photos/89294557@N00/sets/72157623218916835/

Does anything look bad, there? What else can I try? Do I need to worry about the dried flux on the board? (and if so, what's a good way to clean it off?)

Thanks for your help so far. I appreciate your patience while I try to figure this stuff out.


Forum Apprentice
Apprentice

Status: offline

Registered: 01/12/08
Posts: 10

Profile Email    
   
By: Windell (offline) on Wednesday, February 03 2010 @ 11:01 AM PST  
Windell

Well... actually... the relevant solder joints on the chip look fishy as heck; every one of them should look like a shiny droplet that is wetted well to both surfaces.

The dried flux is not an issue.

Check *under* the chip, and make sure that the pins are clear of debris. Can't see that part in your photos, and you probably can't photograph it well anyway.

Assuming that you can touch up those joints so that they look good, then the problem is probably elsewhere. You might try programming with your cable at different angles, see if the problem is there, or perhaps following the various troubleshooting guides on the Arduino site-- if the problem is software after all, that would explain things too.


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: bbk (offline) on Wednesday, February 03 2010 @ 07:08 PM PST  
bbk

OK. I re-redid all of those solder joints. It's surprising how much clearer they are in the photo than looking directly at them. I didn't see them as bad joints until you pointed out what to look for. Thanks for that. They're better now.

I have also done a continuity check from every pin on the ATMega to every point they're connected to by a trace on the top or bottom of the PCB, and everything is solid. I'm checking from chip pin to component leg, so should be taking into account the quality of the solder joints (right?). I did the same for all of the J2 connections, and those check out as well.

I was lucky enough to get the serial read/write program uploaded, and figured out enough Processing to follow what it's doing. I think the problem is in the Tx, more than the Rx, because the Processing sketch stdout sometimes fills up with "Meggy Jr reports: Bad input values." or "...command not understood." And other times, it runs just fine & quiet.

I'm starting to suspect the cable. Everything in the Meggy checks out and I'm not changing anything on the computer between the times it works and the times it doesn't. That leaves the cable (which I don't know how to check beyond just using it.)

I just ordered this after Christmas - any chance I could get you to trade the cable for a new one?


Forum Apprentice
Apprentice

Status: offline

Registered: 01/12/08
Posts: 10

Profile Email    
   
By: Windell (offline) on Wednesday, February 03 2010 @ 07:16 PM PST  
Windell

> I think the problem is in the Tx, more than the Rx, because the Processing sketch stdout sometimes fills up with
> "Meggy Jr reports: Bad input values." or "...command not understood." And other times, it runs just fine & quiet.

Actually, it does that on any setup. The more important thing to test is whether certain orientations of the cable make it not work-- if there's a break or flaky connection near the end of your cable, you should be able to tell this way.

> any chance I could get you to trade the cable for a new one?

Please contact our store about that; this is only tech support.


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: Windell (offline) on Friday, February 05 2010 @ 11:05 AM PST  
Windell

Have you had a chance to test the cable at different orientations, or to try the trick of pressing the rest button some time after auto-reset occurs?

One more important question: are you seeing any flaky behavior besides during programming? If so, that would indicate that there are still loose solder joints elsewhere on the board, causing problems.

I'm still unsure as to why selecting a different board helped. I can't see any reason why that would, and if you come across it again, I'd be interested to hear if it's really reproducible that changing the board type would help. I *think* that it's just coincidence, but it would be good to get to the bottom of 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: bbk (offline) on Friday, February 05 2010 @ 02:38 PM PST  
bbk

Different cable orientation or cable wiggling doesn't make a difference. It won't make the upload work, and it won't make MeggyRemoteDraw fail.

Hitting the reset button during upload doesn't seem to help, either. I tried it both before and after the auto-reset triggered by the upload atttempt. I'll keep trying different timings, though.

Since MeggyRemoteDraw works, doesn't that tell me that the cable is OK? If Processing can talk over the cable, then Arduino should be able to as well, I'd think.

And, since I don't have any trouble running programs once they're *on* the Meggy, doesn't that tell me the ATMega is OK? Or could the "programming" function there be broken with the rest still OK?

The only flakiness is in the upload. Everything else seems OK.

Does that add support to your idea that it's a problem in the Arduino environment? Processing doesn't seem to have any trouble communicating...

So - two questions:
1. Is there something I could do from the Processing side of MeggyRemoteDraw to narrow this down?
2. If I were to get a USBTiny ISP programmer, and try to upload through that instead of the TTL cable, would that give us any new information?

I'll also head over to the Arduino forums and see what I can see. Hopefully they won't close their ears when they hear it's not an Arduino I'm working with...


Forum Apprentice
Apprentice

Status: offline

Registered: 01/12/08
Posts: 10

Profile Email    
   
By: Windell (offline) on Friday, February 05 2010 @ 02:59 PM PST  
Windell

>Different cable orientation or cable wiggling doesn't make a difference.

Great-- that's pretty strong evidence that there's nothing wrong with the cable. Any wiring failure mode that I can imagine would mess with the MeggyRemoteDraw program when you wiggle the gable.

>Hitting the reset button during upload doesn't seem to help, either.

If it did help, that would point to a problem in the "auto reset" circuitry, which consists of the reset pin of J2, C6, R4, and pin 1 of the microcontroller. However, it does not rule out an intermittent problem with one of those components. If, for example, C6 or R4 were cracked or not making a solid connection, it might be enough to trigger reset, but not enough to keep it low during programming. You might keep at this a bit. For example, pressing the reset button right before the end of the 1.5 s reset period... just to see.

> If Processing can talk over the cable, then Arduino should be able to as well, I'd think.

Yes and no. Programming requires three wires (reset, tx, rx), while "normal" serial communication just needs two. There are also some important timing and protocol that need to be managed. If you hadn't verified this on multiple computers, I'd be darned sure that this were a software issue.

>could the "programming" function there be broken with the rest still OK?

Not likely. Chips don't tend to break partially. It will work or go completely. The bootloader should be in "protected" memory that can't be affected with the USB-TTL cable. The full firmware, including the Arduino bootloader and the Attack game are burned simultaneously from a known-good binary ROM image.

>The only flakiness is in the upload. Everything else seems OK.

Yeah, I believe it. The trouble is that there just aren't that many places for the problem to occur:
* The cable
* The connections between the cable and the chip
* The auto-reset circuitry
* The firmware (bootloader)
* The software

And, it seems like we've checked them all.

> Is there something I could do from the Processing side of MeggyRemoteDraw to narrow this down?

Not more than you've done, which is already helpful.

> If I were to get a USBTiny ISP programmer, and try to upload through that

Yes, that's a very good idea. The interfaces are almost independent-- should be very telling indeed. If you did, you can also use it from right in the Arduino environment.


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: bbk (offline) on Saturday, February 06 2010 @ 07:15 PM PST  
bbk

I'm getting the USBTiny. I was on the fence about getting it anyhow for other reasons, and if it might help here, that's enough to get it now, rather than later.

Looking around the Arduino forums, others with a similar issue find success in hitting that reset button, but it's not working for me. Just out of curiosity - what version of the Arduino software are others here using successfully? I've got 0018 now. I started with 0017 and upgraded when the problem first cropped up. Next up is to try older versions on other operating systems. My main system is the Intel-based iMac.


Forum Apprentice
Apprentice

Status: offline

Registered: 01/12/08
Posts: 10

Profile Email    
   



 All times are PDT. The time is now 08:42 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?