error burning 328 bootloader with NKC MaxSerial

Forum 2005-2010 (read only) Hardware Troubleshooting
1

I have a MaxSerial 2.0 from NKC, which originally had a 168 in it. I just bought a 328 from Sparkfun, and am trying to burn the bootloader. In the past I've had no trouble burning the 168 bootloader with my parallel programmer, but for whatever reason it's not working with the 328. I'm getting the following error:

avrdude: verification error, first mismatch at byte 0x7800
0x0c != 0xff

avrdude: verification error; content mismatch

I've tried v13 and 14 of the IDE.

The process I go through to burn is:

  1. Connect parallel programmer between PC and arduino
  2. Plug power into arduino
  3. Select the 328 board in Tools:Board
  4. Select Burn Bootloader w/ Parallel Programmer

It pauses for several seconds, then displays the error.

Any ideas?

2

Humm, it should work. Just so you know it's doable, I used a BoArduino + parallel + PC + IDE REL0013 + Sparkfun 328 and burnt 3 bootloaders with no problem.

So what's different?
Re your process - I always power the chip before I connect to the port - FWIW.
Did you try re-burning a 168 as a test? Good chance your known good setup isn't for some reason. Is the PC (?) your using now the same one that burned the 168s?
I'm not an expert, but that error looks like your just not talking to the chip. Chip plugged in OK?

3

avrdude verifies the content after the upload process. And there was an error.
There are a few possibilities:

  1. your atmega is damaged, or at least the flash memory. Reading or Writing failed. Try another chip.
  2. your programmer produced the error. Try another ISP programmer
  3. problems with your parallel port? Try another PC.
  4. wrong hex file? Which version did you use?
4

Well... I took BroHogan's advice and plugged in power before I plugged in the programmer, and it worked! I did this with IDE 13.

5

Interesting! I'm glad I noted that seemingly small difference.
So at this point it appears that success with a parallel programmer is dependent upon when power is applied to the target board. :o
I'll have to try and confirm this. Thanks for getting back.

6

Let me know if you are able to duplicate the problem in the same way as me. I wanted to try again, but if it was just a fluke that it burned without errors, then I didn't want to risk it!

7

I don't blame you for not wanting to retry it!
I tried it using your process (power after connection) and I was still able to burn the bootloader. Must be a "moon phase" problem.
I do know that if your parallel cable is too long (~3') you can have intermittent problems. :-X

8

My cable is too SHORT, if anything. Good to know, though... I was planning on making it much longer.

9

Your limited primarily by the cables native capacitance and tendency for cross-talk. With conventional ribbon cable, you should be under 2ft, but this largely depends on your parallel ports drive capabilities. Adding a buffer of some kind may dramatically increase your cable lengths.

(For those who are curious, assuming a perfect conductor and zero response delay, you're limited to somewhere around 150 meters for clocked communication at 1MHz, although your pp programmer is likely much slower than 1MHz and your cable is far from ideal, and the ATmega & PC have non-zero processing times - you could also measure the latency and correct for the delay in clock-out to data-back, but you know...).