Recently got the O and Baby-O. I just finished soldering the breakout pins on the Baby-O and powered it up for the first time.
The green power LED lights up. I then checked it using the ISP. Well here’s where the problem starts. Am using AVR Studio 4 to connect to the Baby-O via the ISP but AVR Studio can not detect the chip. I went to the “Board” tab and tried to “Read Voltages” to which I just got “Getting VTARGET… 0.0V … OK”.
I tried this same procedure on the O and I got 4.5V properly, so the ISP is working.
I tried checking the voltage across pin 2 and 6 on the ISP connector on the board and got good voltages.
I double checked my solders, and even though its not pro grade, there are no shorts or arcs b/n signal lines.
Are there any test points or checks I can perform to verify the state of the Baby-O?
One caution on the Baby-O versus the Orangutan on the ISP: The cable goes on the opposite way for the Baby-O. Try flipping the cable around and re-connecting. What you’re describing sounds awfully familiar, and reminds me of when I plugged it in backward.
Still nothing. Tried reversing it as you suggested but its still Not Good (NG). Am connecting the red part of the ribbon to the pin with the arrow as described in the PDF. Unless the way I soldered it is affecting the signals. You see I actually soldered the ISP on the reverse side of the board. Too excited, I guess. Am bad at soldering and I don’t trust my skills at desoldering the ISP header as I might pull out the traces, that would be more headache.
When you say you soldered it on the reverse side of the board, do you mean you soldered it on the side with the chips, or on the other side?
Mine’s on the side with the chips. If yours is on the other, that might explain what you’re seeing. But I’m guessing a cable change is all you need to get going again.
Yeah, I can relate on the whole not wanting to unsolder the ISP connector. A friend of mine soldered it on the opposite side from where he wanted, and by the time I’d taught him (BADLY!) how to use a desoldering pump, we’d lifted two traces. It took a fair bit of patching to undo the damage we did.
To match the AVR ISP header standard, you did need to solder the programming header pins so that it stuck out the side with chips in it (then the plug goes with the red wire/pin one indicator matching the arrow, with the cable going back across the length of the Baby-O) like this:
With a single-row header you could simply flip the connector around and it would work from below, but with a double row there is no way to plug the programmer in properly. In addition to which side of the connector the red wire is on, there is a little raised triangle pointing to pin one, where the wire on that end is routed. This needs to plug onto the pin with the indicator arrow on the Orangutan, and as you can see there is no way to do that from below while covering all the other pins at the same time. Don’t worry though, all is not lost!
If you like, you can build a custom programming adapter that swaps the wires around, but this won’t be as simple as crimping on another receptacle in a different orientation. You really want to block it out with pencil and paper first.
Alternatively, you could try to heat up the solder on each pin one at a time with your iron, while pushing on it from below. You should be able to push it through so it pokes out the proper side. You may have to push each pin in a few short steps, and you might want to try practicing on a protoboard or somethihg first.
If you decide to give desoldering a try, rather than messing around with solder-wick, I would recommends picking up one of these from radio shack:
They’re only $11, and serious electronics guys will laugh at you, but I have never found a better desoldering tool! It is a little on the large-tip side, so you have to be careful not to nudge the surface-mount stuff, but usually when I use this the part just falls out at the end.
With the attached photo as basis, the headers are pointing down. I soldered the pins to the traces on the side of the board with chips on it.
When I first soldered the header, I only noticed the traces/solder pads on the chip side. So I thought that’s where I should solder.
Also since I have some extra wires, I might just rig up a cross over wire. If it works maybe I won’t desolder the headers anymore. I do have those one-hand operation desoldering tool and if worse comes to worse, a wire wick.
Oh ohh! I am able to get the voltage and clock from the Baby-O on the “Board” tab now but for example when I change to the “Fuses” tab I get an ISP Mode Error:
Do you know which traces you might’ve whacked? Depending on what it is it can give you the results you’re seeing.
It takes some fiddling, but if you can trace from the ATMega pins out to the ISP, you know you have a good connection. If not, you may need to jumper something to get it working.
A fiddling we will go… good thing I have a mini-grabber for my DMM or testing could’ve been harder.
PB3 (MOSI/OC2) from MCU to ISP is dead. All other ISP pins seems ok.
I thought I could jumper from PB3 (4th pin from the top on the left pin column) to the ISP but it seems that that PB3 is connected to the MCU through the ISP trace.
Just an update. I just jumped it. Scraped off material on top of the trace got some minute amount of lead on it. Got a resistor clipping and fabricated a jumper. Soldered directly on the trace and to pin 4 of the ISP connector. Looks good on AVR Studio, no more errors.
I don’t know how long the solder will hold on the trace. I’m worried about the stress of putting in and pulling out the ISP cable being transfered to the soldered join, than the board flexing.
That’s one of the same two traces that lifted when this happened with a friend’s Baby-O. The jump you did is exactly what we wound up doing for PB3. I tried to solder directly to the MCU’s pin, but I’m far-sighted, and anyone looking at my hands would urge me never to become a surgeon (they shake too much.) So yeah, we scraped a trace and soldered directly to it.
So far that patch is holding on my friend’s board. It’s not the prettiest board in the world, and there’s a chance that repeat exposure to hands and cables may eventually tear the wire loose. But it can always be re-soldered. If you still have five good joints on the ISP header, I wouldn’t worry too much about it pulling loose or cracking a join.
Thanks everyone! Yup its alive, but it’s still not kicking
I’ve worked on the ARM SAM7S and am using this experience as a basis. I’m getting a weird behavior from my Baby-O. How should the Baby-O behave after downloading a program? It should boot and run the downloaded program, correct!?
In my case my Baby-O is only doing that sequence when it is connected to a powered up AVRISP mkII. If I disconnect or power down the ISP, my Baby-O will not boot the program I copied to flash. Anyone encountered this before? Or maybe I just forgot to setup something?
No, I’ve never seen that before. Mine always starts up and gets running.
Have you checked through all the traces to and from the ISP header? For the center two, the holes the header is soldered into also act as vias (you found that out already). I don’t know about the other four, but I suspect something similar happens on at least some of them. If there’s an oddball short or break, it might make the Baby-O come up in an odd state.
Yup it is a very very oddball short… ISP pin 5 RESET to board header pin AD6.
I am specifying “board header pin AD6”, because MCU pin32 (RESET) to MCU pin29 (AD6) is NOT shorted! ISP RESET to MCU pin29 is also NOT shorted, according to my DMM.
I was actually checking the RESET pin because I didn’t see it going high whenever the ISP is not connected or powered up. AVR910 and AVR042 application notes from Atmel states that RESET should only go active (low) when in Serial Programming mode, additionally the ISP should be able to control this. In my case, when the ISP is connected the RESET pulses momentarily then goes high. When the ISP is not connected or powered off, RESET stays low.
At least it’s just the Baby-O, I can use it as a test environment before going to the full Orangutan, which I haven’t even touched since it came in.
Looking at my Baby-O, the ISP5 pin has a trace on the backside of the board that goes to the RESET pin on the edge header. Past that it’s buried under the header strip, so I can’t see where the trace comes or goes from there.
Since ADC6, RESET (PC6), ADC7, and that edge of the ISP connector are all close together in that corner of the board, I could see that something funky might happen.
But for it to be shorted there but not at the MCU is deeply weird. I’m at a loss.
Just to make sure I understand you right, though: If you’re looking at the Baby-O QuickStart PDF, on the right hand side of the board, ISP header pin 5 shows it’s connected to the bottom two pins (ADC6 and RST)?
TOTALLY MY BAD, I misread the pin outs. ISP RESET was connected to board header PC6 (MCU RESET) and NOT to AD6 as I earlier mentioned. This is actually the correct connection.
So now I am certain that there are no shorts on the board. It doesn’t seem like it but, could I have burned a resistor or a cap? Would a burned cap or resistor pull RESET low all the time? But I think the cap and resistors connected to RESET are located at the top left corners, which I didn’t touch after I soldered the header pins correctly.
Glad to know the wiring’s ok. But this is still deeply weird.
Just to recap (and to make sure I’ve still got my head wrapped around this):
If you plug in your programmer, you can:
Load a program
Run a program
Load a new program
Run that new program (programming works)
But if you unplug your programmer, basically it never comes up running at all?
That I’ve never seen. Though it does sound like reset’s being held active or something. Still, if it was a dead short somewhere, the ISP shouldn’t work either, right?
You are indeed correct. The ISP must be powered up when connected to the Baby-O for it to make any difference.
Yup, I have verified RESET is being held active (low) when there is no ISP connected. Just to be sure I’m not making any more mistakes I’ve attached the signals I’m getting, hope someone can confirm (or refute) these.
Captured when the ISP is connected and powered up. Notice there’s a hiccup (which restarts the Baby-O) near the B (yellow line).
This are the signals when the ISP is not connected.
I’ve actually put aside the Baby-O, so I’ve already disconnected all the wires, and started playing with the Orangutan. I wanted to get the behavior of the Orangutan so that I can compare it with the Baby-O…
As I read Jan’s request before going to bed, I tried one more time… got the Baby-O from the storage bin, reconnected all of my connections power, serial, and logic analyzer and booted the Baby-O AND it ran correctly. This is the 2nd time this has happened. The first time it happened, the minute I rewired the board it wouldn’t run properly again. I did not mention it before because I believe it was a fluke.
Putting a 10K pull up didn’t matter much. I’m powering the board using 2 NiMH batteries giving me 2.681V. I was getting 2.426V. Without the additional 10K I’m still getting 2.424V. I have no reference value for the voltage when the Baby-O was malfunctioning.
As a comparison, when the an unpowered ISP is connected to the Baby-O I get 0.761V and the Baby-O does not run. When a powered ISP is connected, 2.417V.
With the Baby-O functioning properly, the RESET line is pulsing, but pulse length is less than max pulse length so it doesn’t actually initiates an actual reset. I see this pulse on the Orangutan, and the Butterfly too.
I am now thinking of the possible causes of this weird behavior:
a cold joint somewhere
a lifted trace that is being affected by pressure/force applied to the board when connecting/disconnecting wires
bad wiring on my part? the Baby-O is still free standing, I just put mini-grabbers in order to get to the necessary pin.
Will continue to check this out tomorrow and during the weekend (or not, depends if I can get the Butterfly UART to work properly using Procyon avrlib). Time to go to bed now …
