Troubleshooting a programming circuit?

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey guys,

I've been having trouble programming anything using my usbasp and I'm running out of options of things to try.

First off, the usbasp clearly works, but apparently only on one circuit I own - a custom PCB with an Atmega32 on it. Unfortunately the rest of the PCB is junk because I cocked up the Eagle packages, as you do.

I used to use a homemade programming cradle for mega8/168 etc, but even that's giving me a chip not responding message in avrdude. This worked in the past without any issues whatsoever.

I've checked continuity between the DIL socket and the 2x5 header - all fine. I've checked continuity down the ribbon cable - fine.

I just bought a couple of new Atmega324's to see if dead chips were the problem - they don't work either.

For atmega32's and pin compatibles (I've got Atmega324A's and Atmega324PA's here) I made a smaller dongle that plugs into a breadboard. It's basically an ISP breakout board with a 1 row, 6 way breakaway header to the board. Conveniently the Mega32 DIP package has MOSI, MISO, SCK, RESET, VCC and GND in a line. Sometimes using this one works - oddly enough it works more reliably if I press down on the chip as it's being read - but mostly it doesn't. The few times I can get the chip to write, it gives me a mismatch error at the first byte. Otherwise the device signature is usually borked, but often close to the actual - so it might read off 0x112200 instead of 0x112233.

Which all leads me to suspect it's a connection problem. The PCB doesn't seem to have any trouble and clearly that'll have better connections than a bread/stripboard. However, as I say, I've checked the continuity on everything and I'm at a loss.

Suffice to say I've tripled checked the pinout for the relevant chips, but here's a picture of the setup if in doubt:

Any suggestions welcome!

e.g. output:

$ avrdude -p m324pa -c usbasp -v -U flash:w:test.hex

avrdude: Version 5.6, compiled on Jun 10 2011 at 04:15:12
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/

         System wide configuration file is "/usr/local/etc/avrdude.conf"
         User configuration file is "/Users/Josh/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9511
avrdude: safemode: lfuse reads as 62
avrdude: safemode: hfuse reads as 99
avrdude: safemode: efuse reads as FF
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: current erase-rewrite cycle count is -256 (if being tracked)
avrdude: erasing chip
avrdude: reading input file "test.hex"
avrdude: input file test.hex auto detected as Intel Hex
avrdude: writing flash (8006 bytes):

Writing | ################################################## | 100% 5.01s



avrdude: 8006 bytes of flash written
avrdude: verifying flash memory against test.hex:
avrdude: load data flash data from input file test.hex:
avrdude: input file test.hex auto detected as Intel Hex
avrdude: input file test.hex contains 8006 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 4.00s



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

avrdude: safemode: lfuse reads as 0
avrdude: safemode: hfuse reads as 0
avrdude: safemode: efuse reads as 0
avrdude: safemode: lfuse changed! Was 62, and is now 0
Would you like this fuse to be changed back? [y/n] n
avrdude: safemode: hfuse changed! Was 99, and is now 0
Would you like this fuse to be changed back? [y/n] n
avrdude: safemode: efuse changed! Was ff, and is now 0
Would you like this fuse to be changed back? [y/n] n
avrdude: safemode: Fuses OK

avrdude done.  Thank you.

or

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9500
avrdude: Expected signature for ATMEGA324PA is 1E 95 11
         Double check chip, or use -F to override this check.

avrdude done.  Thank you.
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Half of your chip is not being powered (AVCC) and you should have some bypass caps across the supply pins.

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've added a 22uF (all I had immediately to hand...) across each pair of pins which has solved the intermittent detection - thanks!

This may sound dim, but I've never used bypass caps on the breadboard because before it always seemed to trot along without them. The majority of the tutorials on how to make programming cradles/similar all neglect caps too. When I design for proper PCBs I normally add them - perhaps this would explain why that works and this doesn't. But still, my old 28 pin programming cradle used to work like a charm without any caps on it... weird!

Still hasn't fixed the write verification though.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I've added a 22uF
That's OK as the cable is longish but you need 100nF caps, at least 2 of them on each side of the chip between VCC and GND and AVCC and GND. And YES you need to connect AVCC to VCC also.

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I tried a couple of ceramic 100nF's, but they didn't work by themselves (kept getting a device sig of zero). Re-inserting the two electrolytics did, however. Both together works, but still no write - and yeah, I've bypassed and connected both pairs of power pins.

EDIT: OK, I put an additional 220uF on both sides and that verified correctly. Maybe my laptop USB ports have gone to hell over the last year!

The 220uF's work by themselves, but similar to the above 100nF's just give me an incorrect device signature. That would suggest to my limited understanding that the problem isn't high frequency noise?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
That would suggest to my limited understanding that the problem isn't high frequency noise?
You PROBABLY have lots of stray capacitance on the breadboard but that may not be the case with a PCB.

Anyway for the past 35+ years since I have been working with logic stuff I have been brainwashed into using 1x100nF cap on ALL supply pins.

Maybe with global warming in progress one doesn't need to anymore. :)

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That's not to say I think you're fibbing, just in this case it doesn't seem to require them! As I say, if I design for PCB I shove them in, because you can slip in an 0805 anywhere. On the breadboard however, space is pretty limited :)

It's those sunspots I tell ya :D