POR not working with slowly rising VCC

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

I have a problem with an ATTINY44 not coming out of reset when a slowly rising VCC is applied. The datasheet specifies a 10mV/mS minimum rise time on VCC. However, the design has a lot of capacitance on the front end with a relatively high input impedance. BOD reset is enabled.

Atmel support wasn't much help in providing detailed information on the operation of the POR other than what was already listed in the datasheet.

If the POR doesn't work with a slow rising VCC, could the watchdog timer be made to force a reset instead ? If the WDR was always enabled (with fuse setting), would that force a reset in the event that the POR circuit didn't provide the proper reset due to a slowly rising VCC ?

Has anyone had any experience with this ?

Thanks.

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

Hi,
I would try the RC element on reset pin.

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

gahelton wrote:
I have a problem with an ATTINY44 not coming out of reset when a slowly rising VCC is applied.
I don't quite understand what you mean by "not coming out of reset". If the AVR is stuck in a permanent reset state, then nothing inside the AVR can force it out of reset.

Does the chip start to work if you apply a momentary external reset low to the reset pin after the power is stable? What AVR clock source are you using?

Have you tried using the MCUSR register? See the 8006G–AVR–01/08 data sheet page 44 section: 8.5.1 MCUSR – MCU Status Register. Pay special attention to the use instructions at the bottom of this section about clearing MCUSR.

I noticed a typo on page 180 in note 3 of: Table 20-6 Characteristics of Enhanced Power-On Reset. TA = -40 - 85°C. Vpot obviously should have been Vpoa like it is in page 179: Table 20-5. Characteristics of Standard Power-On Reset. TA = -40 - 85°C. Are you sure your AVR Vcc fell below Vpoa after the power off? Maybe your power supply isn't ever getting to a low enough voltage. If you are careful, you could discharge the power supply caps before turning on the power, just for testing purposes.

I would think a failed POR would result in the AVR starting up and running at some random place in program FLASH as well as not initializing any I/O registers. If you enable the WDT with the fuses then your program must keep clearing the WDT. If your code starts in some random place it might keep the WDT cleared, but not run correctly because none of the I/O registers were initialized. This WDT fuse fix might not be reliable.

Is your BOD level set correctly for the ATtiny44 speed and Vcc?
https://www.avrfreaks.net/index.p...

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

The AVR is using the internal RC OSC, and yes, BOD is enabled. The AVR was not running "useful" code at all, but I don't know that I would call it a permanent reset state.

Enabling the WDTON fuse solved the problem.

Although you cannot see the internal reset operation, here is how I think it works (gathered from fig 8.1). All of the reset sources are ored together. Any one of them can cause an internal reset.

The POR may fail to generate a reset signal (active high according to the block diagram) if the VCC dv/dt is less than 10mV/mS. Apparently the oscillator(s) are running, but the main loop of the code isn't being executed. The code could be running wild somewhere because the watchdog wasn't enabled before.

Enabling the watchdog in hardware allows the watchdog timer to force internal resets every 16mS in spite of a failed POR. Once the micro has it's brain in gear, the WDT is now serviced in Main.

The WDT is only serviced in one place (the top of Main). However, you have a good point. If the code randomly started somewhere in flash, and made it into Main without going through initialization, the WDT could be serviced, but the code would be fubared because the system wasn't initialized. I could solve this by checking a variable for a specific value before servicing the watchdog. This variable would be set to this value during initialization. If the variable was correct value, the watchdog would be serviced. Otherwise, the watchdog would timeout and reset the micro.

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

Hi,
I would like to see the schematic of the power supply. If you can improve the supply ramp time you will solve your problem rather than a symptom of the problem.
Regards
Dez Ellis

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

gahelton wrote:
If the POR doesn't work with a slow rising VCC, could the watchdog timer be made to force a reset instead ?

The watchdog was not a good idea, since then you can not see, why your application works wrong.
Also it can happen, that some initialization has failed, but the watchdog was still triggered.

The POR works only, if VCC rises fast and from near 0V.
In all other cases you must use the BrownOut reset or an external BrownOut reset circuit.

Peter

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

danni wrote:

Quote:
The watchdog was not a good idea, since then you can not see, why your application works wrong.
Also it can happen, that some initialization has failed, but the watchdog was still triggered.

The application works fine every time when VCC is brought up quickly. The problem is definiately an issue with the POR rise time.

The VCC rise time (actually the unregulated supply) is not under my control since this product is part of a larger system that supplies power. I chose not to use an external reset chip due to cost.

BOD only works on the falling edge of VCC as decribed in section 10.5 of the datasheet. It does not take the place of POR. That leaves two choices, external reset or watchdog.

The device itself is a not critical display device (not a control device). If the code is loose temporarily (for several milliseconds) because the POR failed, it's not a problem. A variable that is verifed before the watchdog is serviced will fix the uncontrolled code entry problem.

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

gahelton wrote:

BOD only works on the falling edge of VCC as decribed in section 10.5 of the datasheet. It does not take the place of POR. That leaves two choices, external reset or watchdog.

I don't agree with this. If BOD is enabled and Vcc rises slowly, the device should be in RESET until Vcc rises above BODLEVEL. Which datasheet are you looking at? ATtiny44 datasheet doesn't have a section 10.5.

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

I don't know where Section 10.5 came from. Maybe I looked at the wrong datasheet... But,

This quote is from datasheet ATTINY24/44.84 Rev G (01-2008), 8.2.3.

Quote:
When the BOD is enabled, and VCC decreases to a value below the trigger level (VBOT- in Figure 8-5 on page 40), the Brown-out Reset is immediately activated. When VCC increases above the trigger level (VBOT+ in Figure 8-5 on page 40), the delay counter starts the MCU after the Timeout period tTOUT has expired. The BOD circuit will only detect a drop in VCC if the voltage stays below the trigger level for longer than tBOD given in “System and Reset Characteristics” on page 179.

However the actual internal reset works, the effect is real. BOD will not force a reset on the rising edge of VCC to compensate for a failed POR.

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

gahelton wrote:

However the actual internal reset works, the effect is real. BOD will not force a reset on the rising edge of VCC to compensate for a failed POR.

I've always assumed that the BOD will operate from 0 volts up and release when above BODLEVEL. That assumption has probably come from internal reset timer selections which can be omitted if BOD is enabled. However, I've never considered POR operation and whether BOD will work only if POR works...

Have you any information from Atmel that confirms this?

As for your original question - I have no experience on that, but your choice to use elaborate protection on watchdog reset probably makes the system safe enough. You probably shouldn't rely on EEPROM not being written while the AVR is staggering through darkness.

You could feel a lot safer though with external BOD circuitry. Atmel Application Note AVR180 has some examples for non-IC solutions: http://atmel.com/dyn/resources/p...

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

gahelton, I think you are taking a description of "normal" BOD operation out of context. Yes, the hysteresis requires a Vcc drop below the threshold. However, if the BOD never works at all until after Vcc reaches above the trigger threshold, then the data sheet cannot possibly use BOD enabled to substitute for the AVR clock source additional delay from startup (section 6.2 in the data sheet). Yet BOD is clearly used in place a fixed startup delay. Vcc equal zero is well below Vbot minus, so the hysteresis is not a factor.

Is your Vcc even reaching zero or are the power supply filter caps keeping it floating at some small voltage that never reaches zero?

Lets assume the POR really doesn't work. Why doesn't the BOD work? The AVR really doesn't care if it gets a POR or BOD reset, its still a reset.

Since you said you are using the internal RC, 8 MHz is the fastest AVR clock available (the speed grade is 2.7 volts Vcc at 10 MHz). This means a BOD setting of 2.7 volts or higher should be safe. If you use a BOD of 1.8 volts then the BOD operation would malfunction at an 8 MHz clock speed (BOD would release before the AVR was stable). You should be able to set the clock SUT fuses to zero with a BOD of 2.7 volts or 4.3 volts enabled (you never said what your Vcc was). What are your BODLEVEL fuses set to?

Just for fun, you could play with the CKDIV8 fuse setting, but it shouldn't be a factor.

If someone wanted to test gahelton's interpretation, try running a 3.3 volt Vcc ATtiny44 with a BOD level of 4.3 volts from power on. Since Vcc will never reach the BOD threshold it would work if you think the BOD must reach the threshold first. However, if this not the correct interpretation then the AVR will still not work even though Vcc never reached the BOD threshold. Sorry, I don't have any ATtiny44s around to test with.

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

As an experiment, I reprogrammed the BOD level to 4.3V on the device which runs on 3.3V. When the device was powered on, the device did not run.

This means that the BOD was still holding the device in reset (or at least it appears to be). The circuit is drawing current, so the oscillators are running. But the code is not being executed.

This creates a bit of confusion. Since the BOD level is ALWAYS above the POR level, and if the BOD holds the micro in reset until after VCC rises above the BOD level, then what meaning does the VCC rise time spec have ? If BOD has the final say in VCC monitoring, then the dv/dt spec on VCC for POR has no real meaning. It appears that the BOD will always release the reset line last when powering up, and activate it first when powering down.

What is POR used for again ?

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

I enable always the BOD and get always reliable working after power on.
The POR can not do the job reliable and thus all former classic AVRs without BOD are not working reliable.
E.g. EEPROM malfunction was a common problem.
Thus no classic AVR was used on my projects.

Furthermore I select the longest reset time.
Especially on using a crystal this was very important, since a crystal may need >20ms to oscillate stable.

Also on using a crystal the full swing mode should be preferred.
Otherwise the oscillator was very sensitive against noise on VCC.

Peter

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

gahelton wrote:

This creates a bit of confusion. Since the BOD level is ALWAYS above the POR level, and if the BOD holds the micro in reset until after VCC rises above the BOD level, then what meaning does the VCC rise time spec have ? If BOD has the final say in VCC monitoring, then the dv/dt spec on VCC for POR has no real meaning. It appears that the BOD will always release the reset line last when powering up, and activate it first when powering down.

What is POR used for again ?

But there is nothing forcing you to use the internal BOD. With BOD off (default state) POR is the only reset source active, so the rise times stated come into play.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

BOD is optional. The AVR can be run without it, it just can't run reliably at some very low below normal Vcc voltages without it. Therefore a POR is required for non-BOD operation. The Vcc rise time specifies how the POR works. So, if you do not meet the rise time requirement, the POR fails to operate. However when the optional BOD is enabled it provides another reset source.

The thing that bothers me is why the BOD doesn't appear to be working? The only thing that comes to mind is the WDT has its own oscillator independent of the RC. Maybe the slow power up AVR RC isn't starting until the WDT provides another reset (pure, total speculation)? If the RC isn't running, even a working BOD release would be meaningless. Besides, if the BOD never released then the WTD fuse wouldn't work either. So, if the BOD appears to be working, but things are not working..... maybe the RC?

If possible (I don't know what PB2 is hooked to on your circuit) try enabling the CKOUT fuse and checking pin PB2 after a slow power up with an oscilloscope, frequency counter or logic analyzer. First without the WDT fuse then if there is no clock activity, with the WDT fuse.

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

This whole thing has been a mystery to me as well. BOD is enabled at 1.8V for a 3.3V system (no writes to EEPROM).

If BOD was a static system (simple comparator and reference), then it shouldn't be fooled. BOD should hold reset until VCC rose above the BOD level. However, BOD wasn't able to provide the reset after POR failure.

Could it be that BOD has a VCC rise time limit as well ? Maybe the reference used for BOD misbehaves with a slowly rising VCC and releases BOD to early to be effective ?

As far as I know, there isn't any interaction between any of the oscillators and reset. It would seem that the clock(s) would have to be working (at some frequency) to get things started. The internal RC oscillator for the core may not be anywhere near the correct frequency with 1.8VCC and rising, but it should be running. It appears that the watchdog timer clock is running since the WDT works to reset the device.

I'll look into using PB2 and CKOUT fuse to see if the internal clock is running with both WDT fuse settings.

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

A 1.8 volt BOD is not correct for an 8 MHz RC clock or for an ATtiny44.

The ATtiny44V speed grade is only 4 MHz maximum at 1.8 volts (it must be the V part to be specified to run at 1.8 volts). If you use a BOD of 1.8 volts with the V part and use the internal RC oscillator, then you need to set the CKDIV8 fuse and never set the CLKPR register division factor lower than 2 (4 MHz clock maximum) after startup.

The non-V part isn't specified to run below 2.7 volts Vcc at anytime. See the data sheet section 20.3 Speed Grades.

If you are using the full speed 8 MHz AVR RC clock or the non-V part then you need to use a BOD of 2.7 volts.

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

I'm not running at 8MHZ. The RC is running at 8MHZ, but the internal clock is running at 1MHZ using the clock divider.

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

Then you are running the V ATtiny44V chip?

Did you ever try the 2.7 volt BOD?