ATMEGA32 Power on Reset Problem

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

I'm having a terrible issue with the ATMEGA32 running at 16MHz.

My program reads the ADC input in an infinite loop.

If I hold Reset during start-up for about 1 second, the program runs correctly and sampling is at the correct speed.

However, when I rely on the chip to start itself (no reset held low at start-up), the program runs unacceptably slowly (I assume an error with the clock somewhere).

I have tried everything to delay the RESET from being pulled high before the power supply has stabilised;

-0.1uF from Reset to Gnd (to delay start-up)
-BOD enabled and set to Vcc=4v
-CLKSEL set to 16K+64mS

Even written a start-up routine that causes a SECOND RESET after start-up (using the Watchdog)..

Still it does not work. Does anyone know what's going on here? Why does the ADC run slow? How long does it need to start-up? and why haven't Atmel taken this into account? Furthermore, what effect does the value of Caps across the supply have?

Many thanks

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

Have you double checked the fuses (clock-settings)? Do you have proper decoupling (caps between VCC and GND)? Are all VCC, GND and AVCC connected?
I never faced any problem.

/Martin.

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

Hardware cause:
First of all read out MCUCSR register - a reset cause. Preferably with JTAG, but you can easily output this byte to one of the port pins or through serial port just after reset. If the reset cause is something different than Power-Up reset:
- WDRF : watchdog
- BORF : power supply or decoupling capacitor
- EXTRF: /RESET, leave it floating.

I had an accident with ATTiny once, when an overvoltage damaged /RESET pullup. I had to apply an external one and it still works perfectly :)

You use 16MHz quartz so this could be a problem also. Does your UART work? If you do not use it, take OC1A and generate PWM of relatively low frequency(~0.1Hz). Take the led and a stopwatch. Check if uC generates proper frequency.

Software cause:
Another possibility is you use uninitialized auto varlables. This is a nasty bug.

No RSTDISBL, no fun!

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

Sounds like a very odd issue to me. Me, and numerous others, have started running ADC conversions pretty much right off the bat in the main loop without any form of errors.
Can you post a schematic and code?
Does it help if you insert a looooong delay (1 second or so), before you enable the ADC, and then another one before you start measuring? If, as you say, clock stability is the problem, then that ought to fix it, don't you think? But I'm leaning towards something overlooked in the hardware or software.

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

To rule out the crystal (sounds like it's failing to start oscillating) try re-fusing it to use the int-|RC at 8Mhz (the software will probably need to be rebuilt to adapt to this new clock). If that works it is the crystal. By the way is the CKOPT fuse set (it needs to be "full swing" for crystals of 8MHz and above)

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

Hi, thanks for your responses. The clock appears to be running fine since both the UART and SPI bauds are ok.

I tried the suggestion of a delay of 2 seconds at start-up, but still does not work. Still, ONLY if the reset line is held low at start-up does it function properly... problem is, I cannot change the hardware now because the PCB is manufactured...

Brutte, what did you mean by "read out MCUCSR register" onto a port?

I will try and find the slow down cause (double check its the ADC).

Does anyone know where Atmel's official value's and diagram for the reset circuit live? And what if I have more Capacitance on the line (due do decoupling of other IC's on the same line with Caps in Parallel?)
Cheers

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

Do you know what MCUCSR register in ATMega is? By "read out MCUCSR" I meant it would be VERY helpful to you to know its value just after uC reset.

I did not know you are using UART (because you did not mention it in your post). I also do not know if you have JTAG. The easiest way to help you with all the unknowns, and to let you know the value of MCUCSR just after reset is to place in code (I assume your code is in asm (another important thing you did not mention) :

;1.Read out MCUCSR to PORTx, where x={A,B,C,D}
in temp,MCUCSR ;first
out PORTx,temp ;second

With a voltmeter you can check the reset cause. If you want to use LEDs - set DDRx!

But now I know you have UART implemented (and MAX232 onboard) and transmission operates correctly (no frame errors), this means that your 16MHz quartz works perfectly (it would not be so obvious with 8MHz, but with 16MHz it is :)

; 2.Read out MCUCSR to UART
in temp,MCUCSR ;first
;second initialize UART (set baud, enable transmitter etc. )
out UDR,temp ;third

The second option with UART is better, because UART will send byte each time a reset occurs, while read out to PORT is not that helpful.

Anyway, it seems to me that the cause of your problems is a buggy software, not hardware. I opt for uninitialized auto variable.

No RSTDISBL, no fun!

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

Hi guys !

 

I have experienced the same problem. I need to RESET the ATMEGA32 after power up, otherwise it doesn't work.

 

I don't know what exactly is the problem and solution, but, I have noticed that when I program the BOOTSZ0 and BOOTSZ1 Fuse bits, it doesn't require RESET after power up and works perfectly fine.

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

Muneeb,

 

You have now revived two ancient threads and tacked on an identical post to each.  Why?  Your 'solution' of changing the size of the BLS is meaningless unless you give some context.  Like, say, your code.  Do you have a bootloader?  If not, changing the BLS cannot be any kind of real solution.  Rather, if this 'fixes' your problem, it points to something deeper.

"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

joeymorin wrote:
You have now revived two ancient threads and tacked on an identical post to each.

Note: I've deleted the other one so only this copy remains. When I know more about where this is headed I may split this recent discussion off the end of this old thread.

 

Moderator.

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

I bet you are using UART connected to USB --> serial (TTL) adapter to send the data to the PC and TXD output of the USB --> serial adapter is back-powering the microcontroller with between 2.2 and 3.5 V while your power supply is turned off. That way the µC is in the forbidden state (input voltage on RX pin > V+ + 0.5V) and µC is powered (but only partially) even while you do not want it to be powered so after turning on the real power supply it misbehaves. It you then reset the µC with the LOW on the RST pin (pressing the reset button) everything works as expected.

 

I have USB --> serial (TTL) converter based on PL-2303HX chip (Prolific driver) and what I described happens when I am using UART. If I first connect RX/TX/GND from serial adapter to the AVR board and then turn on the power to AVR, UART doesn't work until I reset the device by pressing the reset button. You may try to use 5V step-up + 18650 battery as a power supply and you will notice the LED on the step-up board will be lit (although not with full power) even when you disconnect the 18650 battery. You can then measure the voltage between AVR's RX and GND (it will be around 2.2 V) and then you can disconnect the serial adapter from AVR and measure the voltage between TX and GND of the adapter with opened connectors (it will be > 3V). There is a lot of information about that problem in this topic and I suspect this 10+ year old unresolved topic might be (but not necessarily) related to the same issue.

 

ps

The voltages I mentioned might depend upon what you connected to other AVR pins, the clock frequency and AVR type. I gave the numbers for ATmega8a@1 MHz with only RX/TX connected to the USB --> serial.

Chupo_cro

Last Edited: Sat. Oct 1, 2016 - 12:19 AM