Yet another Device Id = 0x000000 thread

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

Hi all,

I'm new here, great to see a place where's lots of support for AVR freaks. Excuse me for jumping right in on a topic that must bore people here :oops:

I am working on a project building a custom board built around an atmega 328P. The boards are programmed via AVR/Arduino ISP connected to a custom rig equipped with pogo pins. Programming is done by pressing the boards upside down against the pins, with pin holes spaced evenly around the board. It works fine, but the last couple of days we've lost 4 of our 10 prototypes, with the dreaded DeviceId = 0x000000 as the result. We think there's a few possible causes:

- fuses got messed up somehow during programming
- ESD frying the atmega's.

Our boards use the SMD version of the 328P, so it's kind of difficult to replace them. I've been trying to re-establish communication with the chip by soldering a wire to XTAL1 and feeding that with a clock signal coming from another (PDIP) 328P, but that also doesn't work. (I'm pretty sure the setup is ok, because I can clock another PDIP 328P using the "CKOUT-enabled"-328P)

Does it make a difference if the custom board still has the crystal connected, or should I detach it when feeding it an external clock?

Another thing I'm wondering if it is actually possible to get locked out of the chip because of a bad connection during programming, when the programming command doesn't even touch the fuses?

Thank for any suggestions for A) identifying the cause, and B) resurrecting the dead boards :)

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

If the frequency you are feeding in is well away from the XTAL frequency then you might get away with it.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

I should look very carefully at your pogo pin jig.

Then look carefully at your programming script/batch file.

Avrdude is pretty good at reporting errors. Punters are pretty good at ignoring them. Or doing foolish things like using the -F switch.

You can normally apply an external clock directly to XTAL1 pin without removing the crystal.

If you ever get an avrdude "bad fuses" message, I kill avrdude. IME, it is not wise to let avrdude "restore fuses". i.e. don't answer Y or N. just ctrl-C

David.

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

I decided to rule out wrong fuse settings by replacing the 328 with a fresh one. Never did any SMD soldering before so I'm not entirely sure if I mounted it correctly. There is some improvement though.

I still get invalid Device signatures but now they are more or less random (often 0x000002 and 0x000102, sometimes 0x000000 or completely random or actually close to what it should be like 1E9500, and twice I got 1E950F (==328P), but avrdude stopped anyway because it couldn't read the fuses correctly. Setting a differnt SCK clock doesn't make a difference.

I'm using an Arduino Uno as ISP. The SPI lines are going through voltage dividers because the target is at 3.3V. The reset line is protected with a diode and also connected to ground through a 10uF cap. Using the lowest possible baudrate I can see on my multimeter that it is pulled low during programming, but for the rest I have no idea how to debug the connection.

Tomorrow I'll get an AVR ISP to make the whole setup a bit more robust.

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

Genoil wrote:
The SPI lines are going through voltage dividers because the target is at 3.3V.
MISO does not need and should not have a voltage divider.

JJ

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

If I understand correctly, the boards with unprogrammed SOIC microcontrollers are being hand pressed against a row of pins with springs in order to make a programming connection of five lines (MOSI,MISO,SCK,RST, GND)? And the programming signals are pulse trains with widths as narrow as 15 or so microseconds. And you're asking us why this might not actually work flawlessly all the time?

Is this being done to save the cost of five 0.1" header pins? Or is the board so small that the programming technician is holding the board in his left hand over the pogo pins and inputting programmer commands to the PC's keyboard and mouse with the other? And you're shocked, just shocked to find that it doesn't work 100% of the time?

Sorry to be flip. But the internal multi-spring clothespin action of the header socket makes a firm metal-to-metal electronic connection between the header pin on the target board and the header socket that is ribbon-cabled to the device programmer. This is to avoid contact bouncing that is possibly causing to high error rate.

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

joeymorin wrote:
MISO does not need and should not have a voltage divider.

Of course :!: Thanks, I did completely overlook that. Will try to see if that improves.

Simonetta wrote:
...

Fair point. The issue however is, that we have to work with quite restrictive dimensions, not allowing for header pins. I think our initial hand built prototype must have been programmed with the jig over a few hundred times without any glitch (with an AVR ISP though). I just built another jig with Arduino ISP so that we could work in parallel (my team is just 2) until the 2nd AVR ISP finally arrives (today, hopefully).

BTW I'm not shocked ;). I just want to make sure that we don't wreck a lot of boards when we get 200 in next week, because of some stupid mistake like joeymorin just pointed out.

[update]

Just wired the whole thing up again, but then with MISO bypassing the voltage divider. It works flawlessly again. Thank you very much! I guess this is also the moment where I admit I didn't have the voltage dividers in the first place at all, which might be the cause of the busted boards. Or perhaps they aren't busted after all, I'll test that when I get to work :).

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

I do hand held pogo pin programming via a Tag Connect (http://www.tag-connect.com/)with 100% success - ok, all the pins/pads are very close together and the mechanical alignment via the plain holes is perfect, but I don't have to be particular careful at holding the Tag at exactly 90 degrees to the board