ATmega169PV - ISP problem

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

Hi all,

I've some 10 similar boards with ATmega169PV - 8MU - 0642 manufacturing lot. I am using SPI - ISP to program the flash.

This chip uses internal 8MHz oscillator, and it is divided by 8 internally (thru DIV8 fuse), so the core is intended to run at 1MHz.

Vcc is stable 3.3V, obtained from a lab bench-top power supply.

Reset line is on board externally pulled up to 3.3V by a 47k (47k)resistor.

All the boards have virgin ICs, and I use STK500 to do the ISP.

Problem I am facing is, in many boards, initially I was able to program the chips, but later on, the signature is read as 0x7F 0x7F 0x7F. I programmed a simple LED blink code, and then, say after an hour, the chip is not getting recognized by STK500.

I tried to probe the SPI signals thru o'scope, and I see no noise or ringing. I've 100 Ohm resistors in series with SPI lines to tame the ringing.

I also noticed that, during "Read Signature", the MISO line gives some signal between 0 and 3.3V (I mean proper signal levels), but STK 500 reads the signature as 0x7F.

This problem is getting peculiar. In three of the ISP-problem boards, I tried to program the chip thru JTAG mkII, and it works perfectly fine. Even, the fuse bits are correct and intact for ISP operation. But even after that, SPI-ISP interface doesnt work.

SPI signal from STK500 physically reaches ATmega169PV chip.

All good care for ESD has been taken care, and all the above are tested in lab environment.

I came to know that ATmega...PV is rolled out by a new silicon process to reduce the power consumption (picopower), so I am suspecting even the batch of ICs delivered. I am using 64 pin MLF package, so its really hard to probe the IC pins, except the associated PCB traces.

I've sought Atmel tech support, nevertheless, Any of your help is highly appreciated. Thank you.

Regards,
Vignesh

Cheers,
Vignesh

If everything seems to be coming onto your way, then you are probably driving on a wrong lane..

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

I use an atmega169pv at 5v, with clkdiv unprogrammed.... 8mhz.... 19200 baud seems to work well with this combination.... maybe the problem is the slow 1mhz operation requires a very slow isp clock... try 8mhz and see if problem is different?

Imagecraft compiler user

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

The thing that comes to my mind is that normally the value of RESET resistor is recommended to be 4k7-10k.
Don't know if picopower chips are different...
Really don't understand how something that worked to start with will stop work by that resistor value.
Have you tried ISP without .100 resistors?

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

How fast is the ISP frequency? If you are using AVR Studio you set this in the STK500 "Board" tab. The fastest usable would be 115.2kHz (it needs to less than 1Mhz/4).
/Lars

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

Hi all,

Thanks for all of your replies.

@Bob: I shall try using it. Initially (when SPI-ISP was working fine), I set "Clk output on PE5" fuse, and I was able to see nice square waves.

@Lennart: Atmel FAE told me the same thing. I am not sure how this will help during the ISP since STK500 will control the reset line. But I might be wrong, I shall check with 4.7k pull up. Also, series 100E need not be the culprit, MOSI - SCK lines drive target MCU, whose inputs are essentially high resistive, little bit of parasitic capacitive, and bit inductive loads(FRC wires). I should suspect MISO line, where the MCU should talk back with programmer.

@Lajon: Tried! I went down to 1.21kHz, something else is wrong! Something which worked fine, and now it doesnt. I am worried about how this is going to behave on practical field testing.

Allow me some 12 hours from now (its 11pm here), let me check with fresh mind tomorrow morning, and shall post back the results.

Cheers,
Vignesh

If everything seems to be coming onto your way, then you are probably driving on a wrong lane..

Last Edited: Wed. Jul 4, 2007 - 06:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh, also check with a DVM that your ISP-cable don't have intermittent failure. Bend it (especially near connectors) and check that no wire is broken. I had a similar error once, drove me crazy and it took a while to figure that one out.

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

Hi Lennart,

You've replied while I was editing my prev post. Cable is also not faulty, I am able to reprogram another "working" board! Let me close my day now (its terribly long), tomorrow it should be fine!

Cheers,
Vignesh

If everything seems to be coming onto your way, then you are probably driving on a wrong lane..

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

Update: I tried all the above, but no improvement. Anyone having any clue? This is making much of chaos.

Edit: I think the problem is clearly with the device signature. In all the non working boards, the ID reads 0x7F 0x7F 0x7F. I got one working board, which failed to work after 1 hour (when I tried to re program). Is there any problem or glitch during power up or programmer initialisation which spoils the chip?

Cheers,
Vignesh

If everything seems to be coming onto your way, then you are probably driving on a wrong lane..