areid

I've made the board but not attempted bootloading or anything yet. I thought I'd share the biggest problem I've had with assembly and that is the xtal oscillator X2 for the DS1337 real time clock. It seems that either the pad dimensions are too small, or due to the fact that the pins are under the component and not on the sides, that it's almost impossible to reach for soldering, as it just fits directly over the pads. So, I'm not 100% sure it's connected on both sides.

Connecting an oscilloscope probe across the xtal would probably damage it due to the probe capacitence, so I guess the only way to find out would be to get everything loaded and try to run a program that utilises the DS1337.

Drmn4ea

You're right, that part is tricky to solder. This is good feedback - I don't always notice because I've been doing it for so long :p

Probing the crystal shouldn't damage anything, but depending on the probe capacitance it may stop oscillating as soon as the probe is applied, so seeing a 'flatline' would not necessarily mean it was dead (if working, it would come back when power-cycled or maybe just left alone for a bit). I've been able to probe this and see it running (YMMV), but I've also seen probing stop similar watch-crystal circuits.

What I find helpful to solder parts like this is to place it off the pads slightly (e.g. toward the DS1337 or toward R16) so that there is enough pad peeking out to get the iron tip onto. More specifically, I place a bit of solder on ONE pad, heat it with the iron top and while it is liquid, slide the part into place ("mostly" or halfway onto the pads, if the iron tip isn't very small). This guarantees at least one side is soldered, then, solder added to the 2nd pad should flow underneath the part and produce a solid connection there too.

areid

Tim, Good soldering tip. Aside from that I've got another problem with uploading a sketch:

I've bootloaded the new ATMEGA644 using an Arduino Duemilanove w/ ATmega328, I think successfully () since I got a "Done burning bootloader" message, but when I try to upload the standard Blink example on the Mosquino board I get the error:

avrdude: stk500_getsync(): not in sync: resp=0x00

Windows recognises the board ok and assigns a new COM port. The RX led flashed a few times when uploading. I've selected the Mosquino 1.0 board in the IDE and the right serial port, so I don't know whether it's a boodloader problem, bad serial connection or what. I've tried 2 USB cables and get the same error.

It's a power supply problem: The voltage supply Vcc to the ATmega is only 1.465V (needs to be 1.8-5.5 to power the chip). I guess something is either fried or bad placement. May have to scrap it and start again...

Drmn4ea

Hopefully it isn't necessary to scrap the board... with the schematic open you can probably trace power from the USB port down to Vcc and narrow down the source of the problem. E.g. is there ~5V on both the upstream and downstream side of fuse F1? (It will have high resistance if tripped, causing the downstream voltage to sag.) Does it change when the power switch is turned on/off? (suggesting the issue is downstream of the power switch, on Vcc)

(Note the FT232 and Tx/Rx LEDs are powered directly from VUSB, so they will still blink if the power switch is off - this has gotten me before!)