Mega168 programming lockout

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

Does anyone know of a way to get an AVR processor out of the condition where it refuses to respond to serial programming commands? This frequently happens when a programming process aborts for any reason. With DIL chips I can either throw the chip away and replace it, or I can sometimes revive it by plugging it into another circuit and programming it there. With surface mount it is either a case of major surgery to replace the chip, or a whole board needs to be trashed.

I have just had a Mega168 do this to me. First it programmed about 2/3 of the memory, then for the rest it returned the least-significant byte of the address instead of the verified data. I tried halving the clock speed but then it only programmed about 1/3. Then it initialised and (apparently) erased but would not program anything, and finally it would not initialise at all (I can't even get the $53 reply to the initial set-up).

I've tried slowing the clock right down, and/or upping the VCC from 3V to 5V (this has sometimes worked in the past), but no good. It looks like I've got a dead board, and I'm wondering how many more boards I will end up wrecking in the process of debugging the programming interface.

This particular chip has been programmed before using a tried and tested programmer, and had run the program successfully for weeks. Also, the new programming interface has worked successfully in breadboard form, programming a DIL version of the Mega168 many times, and it has also successfully programmed the chip which is now faulty at least once.

Does anyone have any experience of getting out of this problem?

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

You mean you are reciving no response from the chip at all? If the AVR has suddenly decided to lock itself it should return either three constants for the three sugnature bytes, or random bytes (changes each time a read is requested).

If the chip is really completly locked up, then somthing's majorly screwy. Have you tried parallel programming?

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

abcminiuser wrote:
You mean you are reciving no response from the chip at all? If the AVR has suddenly decided to lock itself it should return either three constants for the three sugnature bytes, or random bytes (changes each time a read is requested).

If the chip is really completly locked up, then somthing's majorly screwy. Have you tried parallel programming?


I don't have a parallel programmer, but in any case that would not be an option since this chip is already part of a production board. For this application, serial programming in-circuit is the only option.

The SPI port now does not even respond to the initial "start programming" command - AC 53 00 00 simply echoes back unchanged rather than the 53 being echoed in the third byte, no matter how many times I re-try the reset. It is as if the MOSI and MISO lines were joined together.

As I said, it seemed to die in stages, first programming part of the way, then reading sig bytes but not programming any memory, and finally dying altogether. I found a bug in the programming algorithm that meant after one page had failed to program all subsequent ones would not attempt to program at all, which at least explains why the first attempt gave up part way through (but it doesn't explain why the first page failed).

I also found a problem in the electronics which meant the SCK and MOSI lines might have received +5V pulses (via 100nF capacitors), which as the board was running at +3V could have blown the chip. Oddly, though, the same circuit had already programmed a DIL version of the chip several times without problems.

I think this particular chip is now completely dead. The board current doesn't even change when I apply a reset. However, even if this failure can be explained by my finger trouble, it seemed at first to be an example of something I've seen a lot when programming AVR chips on the bench: when programming fails for any reason (explained or otherwise), the chip frequently refuses to go back into programming mode to try again. It is as if the part-finished programming left some latched condition in the chip, and this does not seem to be cleared by raising the reset line, as I thought it should.

On the bench, I can generally get the chip to respond again by either making sure it is completely powered down (shorting VCC to ground to make sure no memory is preserved by charge left in capacitors), or by running the program startup and erase cycles with a very slow clock (typically 100 microseconds), or some combination of such messing about.

The programming and testing rig I am building is meant to be used by non-specialist people to test boards on a production line. It needs to program the chip and run a set of tests quickly without special handling. The people who will be operating it will not be able to try ad-hoc methods of getting a board to wake up. Any board which does not work first time will go into a box of failures for someone like me to sort out, so naturally I want to keep these to a minimum.

What I really need is some sequence of serial commands which can be absolutely relied on to get the chip into a known state ready to erase and program. If there are any funny states to deal with, my program needs to handle them - the people operating the unit will not have the knowledge or time to do this.