I’m at the St Louis Science Center showing off the new 3PI robot and using BASCOM BASIC to program it. I’m using AVR Studio 4 to actually load the HEX files into the robot.
I program the 3PI to drive forward a foot, turn right, repeat 3 times… a square. The angle isn’t quite right so I change the time delay slightly, compile the code again, and hit PROGRAM on the AVR Studio. It goes about 3/4 through and stops.
Now the LCD displays a series of solid blocks (garbage) and when I attempt to reprogram it I get an error from AVR STUDIO. If I take my friend’s 3PI and plug it in to my machine… everything is fine, I can read it, program it, etc. I figure I have dead or low batteries… so I put Lee’s batteries into my robot… no change, same error. I try another set just to be sure… same thing.
The Pololu USB programmer shows the proper LED indication, but the robot fails and powers off. When you turn it on… same garbled display.
Has anyone else had this issue? Can the unit be revived or do I need to toss it?
I’m really disappointed… I was hoping to work with the kids and all I can do now is sit here and answer questions… no 3PI demo. (My friend is in the competition so I can’t use his.)
Jerry
I have had an AVR chip not program before with my parallel programmer… but since it was a socketed chip, I just put it on a breadboard and applied a function generator to the clock pin… then reset the fuse bits. I can’t even read this one now.
Sorry to hear you’re having trouble, it does sound like the fuse bits got set oddly somehow (maybe the batteries were getting low, etc…). The only thing I can think of to try while you’re out there (if you still are) is turning the programmer frequency down to 125Khz. If the fuses switched over to using the 8MHz internal oscillator (possibly with the divide-by-eight fuse set as well) you would need to turn down your programmer frequency to talk to it.
To set the programmer frequency, go to the programmer window, then either go to the “main” tab and click the ‘Settings’ button under “Programming Mode and Target Settings”, or go to the “board” tab (depending on which version of AVR Studio you’re using). From there select 125 kHz as the programmer frequency and click “write” to set the change. Then try to look at the 3pi’s fuses, and set it back to one of the “external crystal oscillator Frequency 8.0- MHZ…” settings, deselect the “divide clock by 8 internally” fuse, and hit program.
If this doesn’t do it, I don’t know of anything else you can do to diagnose the problem without more equipment, so I hope that was it.
Thanks for the tip… I tried it but it didn’t work. I whipped out my soldering pencil and built a parallel port programmer but it didn’t work either. The robot is fried… I don’t know what failed on it, I’ll send it back to my vendor and attempt to get a replacement.
I tested the parallel programmer with another Atmel just fine, and on another 3PI with no issues. I’m thinking its a solder connection on the board or another component with a failure. (And I’m just not up to swapping the Mega168 right now.
The programmer is pretty simple if you want to build one…
Put a .0022uF between ISP-3 (SYSCLK) and ISP-6 (ground).
Anyway… Pololu USB and the Parallel programmer both fail… so it’s something on the robot. Hopefully I can get a replacement and get some programming done… while it was working it was a hoot to play with. Meanwhile, I’ll wire up a platform with a Mega-168 DIP and a motor driver. I do like the up-voltage circuit… makes a nice constant motor speed. I think it wasn’t a design flaw… just a marginal component that snuck in.
I’m sorry to hear about your problems. Like nexisnet, I suspect your problem is probably with the fuses getting set badly, and once that happens, you cannot really talk to the AVR any more. In general, you should be careful not to turn off the robot in the middle of programming it, and programming it with low batteries (a good sign is it turning off right after you turn it on) can run the same risk since power might cut out in the middle of programming.
What is the 2.2 nF cap for?
You can send the robot back, and we can take a look at it.
I suspect it has something to do with filtering noise during programming. My original cable did not have this on it and worked fine for me… but did not work on my friend’s PC. I added it and it worked fine. On all the cables I built after that (about 200 now) it has worked fine.
As for programming the fuses and such… I’ve been doing this for quite some time now, I started off with the AT902313 then the Tiny-26, Mega-8, Mega 32, and Mega-168. I have had chips get the fuse bit set for external and have hit them with a function generator on the OSC pin to program them and reset the fuses. The software this time is returning “Could not identify chip ID FFFF” which tells me it’s not reading at all. Usually the only time I get that error is when the programming cable was bad or the chip had no power. (The parallel cable version.)
The batteries tested a bit low but nothing that would have been catistrophic… I mean, the robot was just programmed 5 minutes before and zipped across the floor at a brisk walking pace. I changed a couple of time delays and attempted to reprogram it… it was 50% or so and just died. It feels like the chip just died.
I’ll send it in and see what you find.
I think I am going to stick with building robots that have DIP chips for the processor. There is something nice about being able to yank the processor and try another if you have an issue. This is very true when working around kids who tend to run across a carpet floor and touch the board. (static)
