so with no changes to my hardware setup on my chip, with it powered on I went from being able to program to not being able to enter programming mode. I didnt unplug my programmer while testing my setup. (pololu IR beacon into 4 inputs, with both motor outputs running off a 9V). I was testing the logic on my Ir sensors and accidently wrote the line
PINC &= (1 << PD0);
could this have messed my baby-o up, or is there something else that may have happened? any help appreciated.
Sorry to be a bother, but if anyone can tell me if my chip is still good and what to do or if its shot I really need to know. Im using for an autonomous robot project that is due on friday 
and Ill need to pull something out of nothing if its broke.
Thanks
MichaelS
Hello.
Can you tell me what programmer and programming software you are using? Is there any sign of life from your Baby-O? For example, if the last program you successfully wrote to it drove the motors, is it still trying to drive the motors now?
The line of code you accidentally wrote wouldn’t have caused any problems. Did you ever program the Baby-O while its power was off? Did you ever change any of the Baby-O’s fuse settings? If you are using the Pololu Orangutan USB programmer and AVR Studio, try lowering the board’s ISP frequency to 4 KHz under the “board” tab and then try reading the Baby-O’s device signature (an option under the “advanced” tab). For more information on this, you can see our programmer’s user’s guide.
- Ben
Im using the programmer from here, the usb to serial one.
No I never tried programming it while it was off I would always check.
I erased the chip right before I had the problem because of the code I wrote has a search function that was looking for a Ir signal, so teh motors instantly kicked on to find it and its hard to program the bot when its spinning.
im using AVRstudio and I tried what you suggested, checking for the signature and I get
0x00 0x00 0x00
Warning: Signature does not match selected device.
in most likelihood is my baby-o dead?
Thanks,
MichaelS
Still not giving up tho.
Woah, Friday deadline!
So to get this completely straight, you hit the “erase device” button on the AVR studio ISP programming window, and all indications were that the AVR was erased succesfully, then when you tried to download a new program (having made no changes to the robot/wiring since erasing) you couldn’t enter programming mode?
Until we figure out the problem we can’t say for sure, but my guess would be that you haven’t ruined the Orangutan. I’m assuming you’ve already tried the obvious un/replug-reboot everything check. Could you describe (or even better, photograph) the wiring connections you had made to the Baby-O (power source, external devices, etc…) when it stopped working?
A couple of things you might try, if you haven’t already:
-Disconnect everything but power and the programming header and try programming.
-If you’re using batteries as a power source make sure they’re well above 5V.
-Can you verify the six programming cable connections with a continuity meter?
Also, when you set the programmer frequency to 4 KHz, did you hit the “write” button next to the pull down menu to set the new frequency in the programmer? That flummoxed me for a while when I was starting out with AVRs. You can check the current frequency with the “read” button, which should read back 4 KHz or so.
-Adam
P.S. I don’t suppose you’re somewhare nearby Ann Arbor, Michigan. The last person I met on this forum with Orangutan (the original Orangutan) troubles and a class project deadline happened to be only 40 miles away!
yea im in Oklahoma so no good on driving to ann arbor and can I improvise a continuity meter with and led and a battery and some wire Im thinking yes. and yea I wrote the 4 mhz signal to the ISP. I’m gonna try my LED test on the connector and see If I have a problem there and I guess I splice in new wires to fix it if thats what it is. Ill get you a picture of my qiriing diagram in a bit. Its pretty simple though. Voltage in on the vcc and gnd pins. Motors leads on M1 and M2 pins. and 4 inputs on PB0,3,4 and PD0. all my connections are soldered with 24 gauge copper wire so Im gonna have fun undoing that tonightto check. Maybe Ill just cut in the middle of my leads and heat shrink em back together later. Oh yea and my input lines are coming from the pololu IR sensor. My PS is a 9v battery connected to a standard 9V connector with parallel leads going to both my devices (Baby-O and sensor)
PB3 is the MOSI (Master Out Slave In) line, and PB4 is the MISO (Master In Slave Out) line, and they are the data lines used in programming mode. You will have problems programming if these pins are held high, or if enough current is sunk from them when the programmer tries to drive them high. I forget which way it works offhand, but one of these problems on PB4 could cause the device signature misread you saw before. Are you making direct connections from the IR Beacon outputs to these input pins? Looking at the IR Beacon schematic, depending on what the Beacon is seeing, this will either connect the pins directly to ground, or to Vcc through a 1K resistor!
In general, if you don’t have to use them, it’s better not to dual-purpose the programming pins (PB3, PB4, PB5, PC6 AKA reset). I would try desoldering or cutting the inputs to PB3 and PB4 to see if you can program the Orangutan. If that fixes your problem, you should consider moving those lines to other free inputs. If that isn’t an option, you just need to make sure that they won’t drive the lines high or sink current when the programmer tries to drive them high (i.e. with a 10Kohm decoupling resistor* in series with each input, convenient since you just cut the wires!).
*-Can someone double-check my circuit logic, I think this would allow both programming and reading of the IR beacon.
-Adam
P.S. A friend of mine built a PWM motor speed controller with feedback from an optical slit disk detector using an 8-pin ATTiny25. With so few pins he had to dual-purpose some of the programming ones, and I forget which pin was which, but one of the programming pins was connected to the output of the slit detector. He could have gotten around this problem with some resistors and a diode, but it was a simple prototype, so instead he had to rotate the slit-disk to align a slit with the detector before he could program the AVR. Hah!
So did you get it working in time?
-Adam
Nope I couldn’t get it working, I’m pretty sure that a fuse bit got messed up. One of my group members may have accidentally clicked program when it was off but he’s not sure so Im gonna go with he did program it when it was off. My professor gave me an extension until wednesday so I have a new Baby-o coming in tuesday.
But don’t chuck your jammed Baby-O!
Ben, I haven’t tried this yet, but with the pinouts of the Baby-O, do you think an AVR Dragon or STK500 (or JTAG-ICE) could be set up to do parallel HVPROG on the 168 on a Baby-O to get it out of a wedgied state?
The times I’ve majorly screwed up the fuses on an AVR device (like disabling the ISP bit as well as the debugWIRE bit and setting the clock to external crystal on a bare-chip project, I kid you not) I’ve always been able to get it back in HVPROG mode.
Tom
Yea I haven’t given up on it completely I figured there were some ways out of it that would required some external help. I’;; be back around to see what I can do as soon as I get my bot rebuilt. I’ll put up some pictures for you guys this afternoon or sometime soon. Quick question tho Im safe using any of the D pins as inputs because I cant actually find anything that sys maybe you shouldn’t use these pins.
You’re safe using any of the accessible D pins, yes.
PD5 and PD6 are also inputs to the on-board dual H-Bridge chip, but they’re not brought out to the header pins.
-Adam
If you don’t have the hardware on-hand to try HVPROG to get your fuses reset, let me know. I’d be happy to do it for you.
Tom
Hey, Tom.
I have no experience with HVPROG, but it sound like it’s something I should know about. I’ll look into it with regard to the Baby-O pinouts.
- Ben
Looking at the 168 connection sheet for the AVR Dragon, it wants the following pins available:
PC6/Reset
PD1
PD2
PD3
PD4
Vcc
Gnd
PB6 Nope
PD5 Nope
PD6 Nope
PD7
PB0
PB1 Nope
PB2 Nope
PB3
PB4
PB5
PC0
PC1
PC2
The Baby-O doesn’t bring PB1, PB2, PB6, PD5, or PD6 out to headers. So no HVPROG on a Baby-O without putting probes on individual device pins. Rats. Sorry for getting hopes up. Looks like it’s a no-go.
For what it’s worth, I’ve only ever seen HVPROG used on a bare chip. It tends to eat a huge number of the I/O pins, and really isn’t considered an in system programming method.
But it was worth a try.
Tom
sounds good guys. I may be back to try and salvage my "broken: baby-o, but thats another time. Well I’m gonna reput everything together tonight and crossing my fingers it all works properly. Check the projects forum over the next couple days and ill have a nice report I guess you could call it over what I did with pictures and maybe a video of some runs.
Gents,
has anyone figured out how to salvage baby-O? It looks like I bricked mine by messing up fuse settings on it. 
Hello.
Can you provide a little more information about your situation? What programmer are you using? Do you know that you messed up the fuse settings or are you just guessing that is what happened?
- Ben
I’m using jtagice mk2 and AVR Studio. I was trying to get DebugWire going but that didn’t quite worked out from the looks of it.
My guess unless I will be able to attach the pins off babyO to proper wholes on the STK500 board, I’ll be ordering brand new baby-O board ?
Any ideas on what can be done to recover it?
While you haven’t explicitly said so yet, my assumption is that you programmed the debugWIRE enable fuse (DWEN) and are now unable to communicate with the device. Is this correct?
If so, you shouldn’t give up yet. debugWire uses the reset line as a bi-directional interface to the AVR. As such, there are several restrictions on what can be tied to the reset line. From the mega168 datasheet:
If you look at the Baby Orangutan schematic, you can see that the reset line is tied to Vcc via a 10k resistor and to ground via a 0.1uF capacitor. For debugWIRE to work, you need to remove this capacitor. The 10k pull-up resistor should be ok, but it is at the very low end of the acceptable range.
I suggest you give the debugWIRE interface another shot after removing the reset line capacitor.
- Ben
