Category electronics

Over the weekend I received the jumpers for connecting the recently acquired AVR Dragon, so I decided to give it a go this weekend. Because the chips I’m using are programmed to use an external clock, the best programming mode for writing chips stand-alone is High-Voltage Parallel Programming, which doesn’t rely on an external clock.

After jumpering the board for HVPP per the SCKT3200A2 devicesheet in the official AVR Dragon documentation I tried it out on both OS X and XP, and it mostly works well, except for programming the EEPROM. For some reason, EEPROM seems to just not write, and thus validation fails. If I insert a chip with EPROM already programmed properly, validation will work, so reading is definitely working and nothing is (even partially) overwriting the existing data.

There are no problems writing the Flash or fuses, and since writing to both Flash and EEPROM use the same lines, I don’t think it’s something mis-jumpered. Nor do I believe the problem is the chip itself, since I’ve tried multiple chips which can be programmed in an STK200 (parallel port bitbang) programmer.

Here’s the command lines used with the AVR Dragon which errors while validating the EEPROM:

avrdude -p m8 -P usb -c dragon_pp -U lfuse:w:0x3f:m -U hfuse:w:0xdf:m -U flash:w:SDrive.hex:i -U eeprom:w:SDrive.eep:i

Here’s the one used with the STK200 clone, the same chip, and the same version of avrdude, which works just fine:

avrdude -p m8 -c stk200 -U lfuse:w:0x3f:m -U hfuse:w:0xdf:m -U flash:w:SDrive.hex:i -U eeprom:w:SDrive.eep:i

Here’s the actual error:

[Working stuff here cut...]
avrdude: verifying ...
avrdude: 8084 bytes of flash verified
avrdude: reading input file "SDrive.eep"
avrdude: writing eeprom (329 bytes):

Writing | ################################################## | 100% 36.51s

avrdude: 329 bytes of eeprom written
avrdude: verifying eeprom memory against SDrive.eep:
avrdude: load data eeprom data from input file SDrive.eep:
avrdude: input file SDrive.eep contains 329 bytes
avrdude: reading on-chip eeprom data:

Reading | ################################################## | 100% 33.60s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
0x72 != 0xff
avrdude: verification error; content mismatch

avrdude: safemode: Fuses OK

avrdude done. Thank you.

If anyone has an idea as to what might be wrong here, I’d love to hear it. This is exactly the same problem I get on both Windows XP (avrdude v5.6 from WinAVR-20081205) and OS X (avrdude v5.5 from AVRMacPack).

For what it’s worth, I have posted this here on the AVR Freaks forum, but it doesn’t seem to be receiving any replies.

UPDATE: It seems that this is a problem with avrdude. I can program the chip with no problem in HVPP mode using AVR Studio. This would be a good time to have a logic analyzer. Maybe I could actually fix the problem.

Today I just happened to find a package containing 25 brand new SIO connectors in the mailbox. Because of this I have reopened orders of wholly assembled SDrive NUXXs. I’ve also put the assembled devices on the SDrive NUXX ordering page, so they can be ordered by people without my manually sending invoices.

While doing the PCB layout stuff for the SDrive NUXX, I’ve spent a lot of time trying to make the traces as simple and attractive as possible, while ensuring the components on the PCB are reasonably well spaced and thus easy for an average DIY person to solder. When I do this, I set up the board with two layers, with the top primarily being the ground plane, and the bottom holding as many of the other connections as possible.

After establishing part footprints and placement (mostly based on front / rear panel controls in the SDrive NUXX’s case) I then try to lay out the rest of the parts, fitting them together like Lego, taking into account things that need to be near each other (caps and certain things), and other stuff like that. Then I route the board, trying to keep as many traces on the bottom as possible and moving repositionable components as needed. Of course, surface mount parts often require their traces to be on the top, but generally most things can be kept on the bottom.

Once everything connected in a layout that is looking good I’ll turn off everything but the top and bottom layers and associated pads, vias, and airwires. I then look at every top layer trace, and if it’s not needed for an SMT part or crossing over a trace on the bottom, I’ll try to move it to the bottom.

Next I’ll turn alternate showing only the top or bottom layers, as shown above. On the left is the top (or component) side with its traces in red, and on the right is the bottom (or solder) side in blue. Looking at just one side at a time I can more easily see traces routed in unnecessarily complex patterns. Sometimes I’ll have stairstepped a trace or routed it around something when a much simpler, straighter path would do. I find that having more layers (documentation, part outlines, part names, etc) turned on while doing hand-optimizing causes me to keep traces of areas where they can safely go, particularly under other components. Hiding this information clutter lets me focus on the bare wiring itself making the task even easier.

After a few rounds of this I generally find that the result is a layout with simple, direct, and well organized traces.

Buying twelve SD cards at a time feels a bit odd. However, they are needed, as the assembled SDrive NUXXs each come with one. They’ve all now been reformatted as FAT, labeled (SDRIVE_NUXX), and had SDRIVE.ATR copied to the root. Checksums were done to ensure that the file arrived intact.

I’ve also got a line on some more SIO connectors, so it’s possible I’ll be able to open up the ordering further than I had before. Being able to do this would be good, as I’ve already got a couple people on the wait list.