HELP PLEASE! A really hard time with ATmega644A and crystals, fuses etc.

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

Hello to everyone,

Just before giving up, really frustrated, almost mad with anger... angry

I ask any of you that can suggest me a workaround other than building another test board... or doing away with AVR stuff altogether.

 

I have designed and built a prototype PCB with an ATmega644A-AU and a crystal at 9.216 MHz with 22 pF capacitors connected to it.

The '644A is connected to an LCD and a Dataflash(TM) memory through SPI.

I use STK500 with AVR Studio 4 to program the '644A using ISP. My code is written in C.

 

My nightmare started when I mistakenly set the fuses; my '644A was "bricked" and I could not bring it back to a functional state.

After browsing through the forums here, I built a crystal oscillator using 4011 on perfboard and successfully revived the microcontroller; this time, I selected "Ext. Crystal Osc. 8.0 - MHz" on AVR Studio.

After downloading code to the microcontroller, I noticed that operation was erratic. The whole system kept resetting at a rate that was not stable, however this happened rather frequently (once in a minute or two, I guess). That erratic operation seemed to happen even with a very simple program that just displayed text on the LCD and nothing more than that.

I tried to measure the clock signal on XTAL1 pin of the '644A using a "vintage" 'scope (Tektronix 454; okay, I know that in that way, the oscillator is loaded with the probe impedance, but it is a quick way to check if anything happens at all). Amplitude was small, less than 1 V. I thought that I should use the "full-swing" fuse option, but when I had set that earlier that day, I got the microcontroller "bricked " again and I had to revive it using that crystal oscillator I built.

 

I spent many, many hours last morning browsing through the forum trying to find a clue to that strange problem. Almost everyone stated that full swing should be used at clock rates above 8 MHz. Indeed, this made sense.

Later, in the evening, I tried to program fuses but without success. I tried removing the crystal, the capacitors connected to the crystal's terminals, soldered the crystal back to the board (2 or 3 times; I really don't think it should be okay to do it once more) with the external crystal oscillator connected to XTAL1 pin of the '644A. Even with ISP frequency set to 1.2 kHz (minimum), no communication could be established between STK500 and my '644A.

 

I tried soldering a 10 nF capacitor across ~RESET pin and ground (I have a button switch for resetting the microcontroller; I placed the capacitor between the two terminals of the switch) after having gone through AVR042 for another time. It was at that point when I noticed that my '644A kept resetting at a constant rate, for I thought of placing the 'scope probe on the ~RESET line and check what was going on there.

 

Following that, I thought of desoldering the microcontroller and replacing it with another one; I tried to do so, but I could not do that. I cleaned the PCB from all that flux thoroughly, hoping that things would be better. However, no luck again. I cannot revive the microcontroller using the external oscillator.

All I have now is a non-working prototype with a microcontroller that keeps on resetting; having the STK500 connected through the ISP header has no effect to that.

 

Can you please suggest me what I can do to recover fuse settings on that microcontroller that keeps on resetting?

Is "full swing" the correct setting for a 9.216 MHz crystal?

Why is the microcontroller resetting all the time?

Is it possible to destroy the clock circuitry in the '644A by applying an external clock signal to recover fuses?

 

P.S.: It is not the first time I build a PCB with an AVR; earlier this year, I had build another prototype using exactly the same microcontroller and a slightly different crystal (10 MHz and without pin for grounding the case). Everything worked fine! But I did not copy the fuse settings and now I had to go through all this...

This topic has a solution.
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You own a STK500.    So you can always supply an external clock.

Your mega644 is unbrickable.    It does not have a RSTDISBL fuse.    You can NOT remove SPIEN by SPI.

 

With an external clock,   read the chip Signature and the value(s) of your fuses.    Report here if you are unsure of the correct settings.

 

David.

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

Perhaps disconnect lcd and spi dataflash and just get a led program running solid. Something like 'flash 5 times at power on'. Check list of things to check for that make avrs flaky if not done: vcc and avcc connected to 5V? all gnds connected to gnd? Easy to check with ohmmeter. .1 or .01 bypass caps on ea vcc pin? brown out set to 4.3V? next step is test lcd.

Imagecraft compiler user

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

Here are the fuse settings I use for my boards with mega644PA. They should apply to the 'A' only version to:

 

FUSE SETTINGS:    FC,D1,DF.    (ATmega644P-20AU)

Brown-out Detection                - 4.3V
On-Chip Debug enabled           - NO
JTAG Interface enabled            - NO
SPI Programming enabled        - YES
WatchDog Timer always ON      - NO
Preserve E² thru Chip Erase      - YES        (or set as required)
Boot Flash Sector size              - 4096
Boot Reset Vector enabled        - NO
Divide Clock by 8 internally       - NO
Clock Output on PORTB,1         - NO
Master Clock Source                - LP Xtal (20MHz), 16k+0ms (w/BOD)

 

Note the LP xtal setting even for 20MHz. Should work fine. The full swing mode, as I understand it, is for noisy environments and/or when using Xtal2 pin to drive other devices.

Also you can measure the clock on PB0 without loading the xtal osc if its not used for GPIO.

 

Based on what you are saying, I reckon it might be worth probing your supply. And contrast that with BOD settings. Have you measure the boards current consumption? Is any regulator getting hot. Maybe going into thermal shutdown protection.

Given you have succeeded in making a functional board in the past, maybe compare the differences in the design.

Check for PCB errors or assembly errors.

 

If you can get some software to actually run long enough before a reset, perhaps you could get it to tell you what type of reset occurred.

- if you have a serial port, send it out that.

- if you have some LEDs see if you can flash them in a particular fashion.

 

Steve

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

@schtevo,

 

I find hex values of fuses far less ambiguous.    If you want to post the "full-English",   why not add the hex values too?

 

@everyone,

 

Your Dataflash is either 3.3V or 2.5V.     So it is extremely unwise to run your AVR at 5V with BOD=4.3V.

I would definitely use regular HF crystal options first.     If you have a 'low-activity' crystal,   the LP low-power setting may not be reliable.

You can try LP after you have read the crystal data sheet.

 

David.

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

schtevo wrote:

FUSE SETTINGS:    FC,D1,DF.    (ATmega644P-20AU)

 

@David,

 

Are these not hex values for the fuse bits?

Or were you perhaps referring to the boot sector size?

 

"Friendly names" are there for a reason if you ask me. Makes life easier.

 

Interestingly I have frequent "issues" with my boss regarding modbus configurations.  He always says "Function Code 0x04" where as I always say "Read Input Registers".

Everyone has their own personal preferences I suppose.

 

You are absolutely correct however; when programming a virgin chip, I used the descriptive list to aid in setting the tick-boxes and then use the fuse byte values (hex) whenever confirming the fuses are correctly programmed.

 

Steve

Last Edited: Wed. Oct 8, 2014 - 07:33 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Good Morning to everyone and thank you for your kind response.

 

David (david.prentice), I have been trying to read the signature by applying an external clock signal using my 4011 oscillator across XTAL1 and GND pins. However, I had no luck at all; even at ISP frequency of 1.2 kHz, I did not manage to.

Bob (bobgardner), I detached the LCD from the board - it sits on a low-profile socket for easy removal - and tried again but with no luck.

 

Maybe I should build a more robust and simple oscillator, perhaps an R-C with 4011 or 4093. In fact, the output swings from 0 up to 3.3 V but it has enough jitter.

Any frequency from 40 kHz to 1 MHz would do - this is what I read yersterday in one certain post here (yet I cannot recall where exactly so as to quote it here). Is this correct or am I missing some critical detail here?

 

From what I read in your comments, it is not necessary to replace the microcontroller or the crystal, right?

 

As far as the earlier design is concerned, the differences with the current one are:

1. The earlier design was a 4-layer PCB; the current one is a 2-layer PCB with ground planes both on top and bottom sides, shorted together with plenty of vias scattered around. (This was done for reducing development cost.)

2. The crystal in the earlier design was at 10 MHz; in the current one, it is at 9.216 MHz so as to set the USART at 115.2 kbps precisely. (At this moment, I have not activated the USART yet.)

3. The dataflash was not present in the earlier design; I added that in the current one in order to avoid using the on-chip EEPROM for storage and recall of settings.

 

I have the following things in mind and want to try them in the afternoon:

Build a relaxation oscillator at, say, 100 kHz using 4011 or 4093 (that is all I have in my box) and try again reading signatures etc.

Build another board with only the '644A, the crystal, its capacitors and the ISP header. Using that board, I would try the fuse settings and the simple program with blinking LEDs and so on; when everything would have worked OK, I would go on adding the rest of the components.

I will report the results from ny experiments here.

 

What else do you suggest?

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

I use STK500 with AVR Studio 4 to program the '644A using ISP. My code is written in C.

If God gave you a genuine Atmel STK500,   why not use it ?

 

OTOH,   if you have a programmer that uses STK500 protocol,    it may not have programmable VCC, AREF, Clock, ...

 

Yes,   you can make an oscillator with a pair of gates.    It is a lot easier to just use another AVR.

 

It sounds like you should check your pcb for shorts,  connectivity.     Component values etc.  e.g. are the caps really 22pF and not 22nF?

You can do this with a magifying glass and a multimeter.

 

David.

Last Edited: Wed. Oct 8, 2014 - 08:14 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello again!

Here is a summary of what I have tried so far tonight:

 

  1. I built a relaxation oscillator using a 4093 chip that I had in my box. Frequency was around 50 kHz. I connected that to the board, tried to read fuses but did not succeed.
  2. I assembled another PCB with only the '644A, the decoupling capacitors, the crystal and its capacitors, the reset button and its pull-up resistor and the ISP header. I hooked up the PCB to a 3.3 V supply, turned the supply on and tried to read the signature. The first attempt was successful! (however, I did not write down the signature bytes). Following that, I tried to read fuses but... did not manage to: AVR Studio keeps on showing that dialog box stating that "a problem occured when executing this command" and so on.
  3. Note that in steps 1 and 2 I used the minimum frequency of 1.2 kHz to read signature and fuses.
  4. Following that, I tried 5 V as power supply voltage since no other components are assembled on the new PCB. Even then I could read neither signature nor fuse bytes.

 

So back to square one...

Any suggestions, anyone?

 

STOP PRESS!

Just before calling it a day, I tried to heat up the pins of the microcontroller; I noticed a couple of pins that could be suspicious for a bad joint.

After that, I tried to read signature and here is what I got:

First attempt: 0x1E 0x00 0x00

All other attempts: 0x00 0x00 0x00 - but this time without any error message! (Now that's really weird, isn't it?)

Following that, I read fuses and got everything with 0xFF.

After some minutes, I tried to read signature again and got the familiar error message. Seems that some critical joint cooled down and stopped joining things together...

 

Then I tried heating the pads with my soldering iron again... and repeated the above procedure.

Here is what I got:

Fuse bytes: 0x62 0x99 0xFF

Signature bytes: Tried to read them after a minute or so and could not!

(After another pad heating and reading attempt: 0x1E 0x96 0x09)

 

I suspect that something must be wrong with the internal RC oscillator of the '644A. I had encountered a situation a few years ago with MSP430 at work: in order to connect to the bootloader, I had to rub the chip with my thumb or heat it a little with a hairdryer (!) or by placing the soldering iron tip close to it.

 

And a last one:

After several heating up and reading cycles, I thought that something must be wrong with the soldering flux I used:

I used RH63 solder wire (it contains lead) and Weller Loetwasser flux (comes in a plastic white bottle). When I applied flux on the pads and then soldered them, the flux was heated very quickly and got the PCB messed around the '644A.

I cleaned the PCB using that old toothbrush and isopropyl alcohol. Then I tried reading signature and fuses and everything works OK up to now, without having to heat the pads again.

 

The more old I grow, the more I learn. (Γηράσκω αεί διδασκόμενος, in Greek)

 

Now it is time I went to bed. I'm going to leave the PCB working all night.

I hope that when I wake up it will be still working...

Last Edited: Wed. Oct 8, 2014 - 11:36 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm glad to hear you have it working.

 

Bob stated:

Check list of things to check for that make avrs flaky if not done: vcc and avcc connected to 5V? all gnds connected to gnd? Easy to check with ohmmeter. .1 or .01 bypass caps on ea vcc pin? brown out set to 4.3V? next step is test lcd.

 

Do go through this, item by item, and make sure your circuit design is OK.

 

If any of it doesn't make sense, then ask.

 

JC 

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

schtevo wrote:

@David,

 

Are these not hex values for the fuse bits?

 

My apologies.    I missed the "FUSE SETTINGS:    FC,D1,DF.    (ATmega644P-20AU)"

 

Yes,   you provided the best information.   i.e. hex values + "Friendly names"

(I would be happiest with "lfuse=0xDF" as the clearest syntax)

 

In an ideal world "Friendly names" would be ideal.    However,   programming software comes from all over the world.

A Chinese or Indian or Iranian IDE can be confusing.

 

David.

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Good Morning to everyone!

Early today I checked again the PCB I assembled first that had the original problem.

I found a quite well hidden short between pins 3 and 4 (that is, SCK and ~RESET). It was behind the pins and did not noticed that at first.

After removing that, I heated up all pads to reflow the solder on the pins and powered up the PCB. I read fuses and signature without problems.

 

Therefore, I mark this as a solution:

1. Check out for shorts very, very carefully;

2. Try to use a soldering flux that will not sizzle when heated up (have a look at my previous post here).

 

Thanks to everyone concerned about that and gave a hint.