Solved: Unreliable power-up reset

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

I'm using an ATTiny841. The fuses are low 0xe0, high 0xd4, ext 0x01.

 

The problem I'm having is that power-up reset is unreliable. It's entirely possible that this is because the clock is taking too long to start. Whenever it doesn't properly start, briefly shorting !RESET to ground makes it start normally.

 

I can't fix the clock source. What I'm inclined to do is add a power-up !RESET hold-down circuit to give a couple extra hundred ms of RESET on power-up.

 

  1. Is there a best-practice method for doing this simply and cheaply?
  2. Can anyone think of anything better to try? I could turn on the WDTON fuse, but what's the power-up configuration of the watchdog? I can't seem to find that in the datasheet.

Last Edited: Fri. May 6, 2016 - 07:32 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Whenever it doesn't properly start,...

So, what are the symptoms?  Does the applicable reguister indicate a restart cause?

 

AVR's just don't "not start" if there is a clock.  It does the first instruction, then the next, then...

 

I'll paint a scenario for you.  You have a character LCD with an init sequence that doesn't do any feedback or retries.  And you have no startup delay, and the LCD is much slower to init, and thus your LCDinit hangs forever, and the AVR has "unreliable power-up reset".

 

There are many similar scenarios.  First thing in your AVR app, set port directions appropriatly.  Then delay as many milliseconds as your app can handle.  I usually use 100 but start here with say 250.  If you do that, does the AVR power-on startup become "reliable"?

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

theusch wrote:

Whenever it doesn't properly start,...

So, what are the symptoms?

 

It does nothing until externally reset by bringing !RESET low briefly.

 

Quote:

  Does the applicable reguister indicate a restart cause?

 

Well, sure. After I hit !RESET, it says that it was externally reset.

 

Quote:

 

AVR's just don't "not start" if there is a clock.

 

That's just it. I believe the clock takes so long to start (or that as it starts it's wonky for a brief period) that the tiny gets wedged.

 

Quote:

  It does the first instruction, then the next, then...

 

I'll paint a scenario for you.  You have a character LCD with an init sequence that doesn't do any feedback or retries.  And you have no startup delay, and the LCD is much slower to init, and thus your LCDinit hangs forever, and the AVR has "unreliable power-up reset".

 

There are many similar scenarios.  First thing in your AVR app, set port directions appropriatly.  Then delay as many milliseconds as your app can handle.  I usually use 100 but start here with say 250.  If you do that, does the AVR power-on startup become "reliable"?

 

 

Yeah, I don't think that's what's going on here. I have a pair of LEDs that are driven directly by two pins. When the code starts normally, they start blinking. When this is going on, they don't. Hit RESET and they start right up.

 

The (external) system clock is coming from an off-board rubidium oscillator buffered by a self-biased inverter. My theory at the moment is that at power-up, the rubidium oscillator takes a while to get going. Thus my idea to just hold !RESET low for a couple hundred ms at power-up as a workaround.

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

So, as I said -- init your port directions, and delay a few hundred milliseconds.  If that works -- probably your app IME.

 

Does that model have CKOUT?  Look at the pin with a 'scope...

 

Startup time setting?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

I could look at CKOUT, but I could also just look at the clock going in. I haven't done that yet, because at the moment it's just easier at power-up to short !RESET to get the code to start. I could set up my scope to trigger on rising Vcc and one-shot capture the clock. I strongly suspect that it won't be pretty, and that's what's going on here.

 

There's a wire going from PB1 through a 330 ohm resistor to an LED anode (the cathode is grounded). I really fail to see how an initialization delay would make any difference to that. In addition to that, USART0's pins are connected to a mini-DIN4 and I'm watching for diagnostic output there. Again, there's none on some power-ups (but not all) until/unless I manually reset.

 

For the ATTiny841, there's only one SUT fuse, and it's value must be zero when using an external oscillator (hence the lfuse of 0xe0). The datasheet doesn't talk about what that means, but i would imagine it means that the startup time is pretty short. Which takes me back again to pulling !RESET low for a couple hundred milliseconds...

Last Edited: Thu. May 5, 2016 - 11:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yet you don't seem to want to try any of my suggestions, including the simple delay.

 

Re capturing startup cause:  You need to "log" every one to see if there is an intervening reset.  (e.g. if you see power-on followed by your external, you know it is your app...  And you could set up the watchdog...)

 

BOD?  That is another very common scenario.  Start up, external devices start drawing power, Vcc drops, AVR runs amok, ...

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

How long is the lead connecting the off-board Osc to the uC's PCB and to the uC?

Is it a shielded cable?

Where is the off-board Osc ground connected to the uC's ground?

 

Is the off-board Osc driving anything else which can show that that Osc is actually working when your PCB fails?

 

Do the off-board Osc and the uC share the same power supply?

 

Adding a delay won't help if the off-board osc isn't oscillating.

 

It is an interesting question if the uC powers up quickly, but the Osc takes a while to become active.

 

Does the uC start up correctly, and reliably, if you run it off of the Internal 8 MHz Osc?

This would help to validate your power supply, by-pass caps, software, etc.

 

What happens if you power up the uC using the internal 8 MHz Osc, wait 250 mSec as Lee suggested, flash your leds a bit, and the switch to the off-board Osc?

 

JC

 

Edit: Typo

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

theusch wrote:

Yet you don't seem to want to try any of my suggestions, including the simple delay.

 

 

I can't fathom how it alters anything.

 

Quote:

Re capturing startup cause:  You need to "log" every one to see if there is an intervening reset.  (e.g. if you see power-on followed by your external, you know it is your app...  And you could set up the watchdog...)

 

I do that. There is no intervening reset. Nothing comes out until I hit RESET, then it says it was EXT_RESET.

 

Quote:

 

BOD?  That is another very common scenario.  Start up, external devices start drawing power, Vcc drops, AVR runs amok, ...

 

 

I just don't understand why you doubt that it's possible that the clock in this particular case is unreliable at power-on.

 

I will grant you that it is uncommon for an oscillator to be unstable at power-up if you will grant me that clocking an ATTiny841 from a rubidium oscillator is similarly uncommon.

 

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

DocJC wrote:

How long is the lead connecting the off-board Osc to the uC's PCB and to the uC?

Is it a shielded cable?

Where is the off-board Osc ground connected to the uC's ground?

 

Is the off-board Osc driving anything else which can show that that Osc is actually working when your PCB fails?

 

Do the off-board Osc and the uC share the same power supply?

 

Adding a delay won't help if the off-board osc isn't oscillating.

 

It is an interesting question if the uC powers up quickly, but the Osc takes a while to become active.

 

Does the uC start up correctly, and reliably, if you run it off of the Internal 8 MHz Osc?

This would help to validate your power supply, by-pass caps, software, etc.

 

What happens if you power up the uC using the internal 8 MHz Osc, wait 250 mSec as Lee suggested, flash your leds a bit, and the switch to the off-board Osc?

 

JC

 

Edit: Typo

 

You can't change the system clock source on an ATTiny841 without changing fuses.

 

I'm fairly confident that the power supply is functioning properly. The power supply powers both the rubidium oscillator and the microcontroller, so both power-up at the same time. The digital circuitry in this design is quite mature, as it's been used with OCXOs for at least a dozen design revisions. It is now being adapted for use with a rubidium oscillator. I am fairly confident that the input conditioning from the oscillator is functioning properly, because I can see the output on a scope and it's fine. I have not gone to the trouble of examining the behavior at power-up, but have reason to believe that its behavior at power-up is questionable, which is why I came here asking about power-up RESET extensions.

 

Can we all just please start off with the presumption that I was not born yesterday and that the reason I asked the exact two questions I asked at the start of this were because that would lead me the quickest to the solution?

 

I promise that if I implement a power-up RESET delay and it doesn't solve the problem that I will come back and genuflect and say you were right.

Last Edited: Fri. May 6, 2016 - 12:18 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Can anyone think of anything better to try?

Let's see, that was your request for additional input, and you shoot it all down.

 

If you want to do yet one more revision on your PCB then add a formal reset chip.

 

If you want a less costly approach, try an RC, but then you need a jumper to enable it, or disable it, as a descent sized "C" will prohibit some forms of programming.

 

Lee and I both gave you suggestions that don't require a rework of the PCB.

 

 You can't change the system clock source on an ATTiny841 without changing fuses.

?

 

I don't use Tinies very often, so I actually looked at the manual before replying.

My suggestion was based upon Section 6.6 Register Description, 6.6.1 CLKCR-Clock Control Register, where in it states:

 

Bits 3:0-CKSEL[3:0]: Clock Select Bits

These bits select the clock source of the system clock and can be written at run-time.

 

I, also, "wasn't born yesterday", and have done a fair amount of troubleshooting over the years.

 

I'm out.

 

JC

 

 

 

 

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

Alright, I stand corrected on the CLKCR register.

 

I ran the experiment you suggested. I fused the controller for the 8 MHz clock, set up a delay and then switched to the external oscillator and the unreliable power-up condition almost went away. I say "almost" because what happened after that was that the watchdog reset the system once or twice. In short, I was right about the reason for the unreliable power-up, but was not pessimistic enough about the quality of the incoming clock.

At power-up, this rubidium oscillator sweeps across a frequency range surrounding 10 MHz searching for a physics lock from the rubidium cell. While it's doing this, there's a !READY output line that's kept high (and pulled-up by the AVR too). The range across which this search takes place is something like a couple dozen PPM or so, and 6.2.1 of the datasheet advices keeping the clock frequency within 2%, so that seemed like it should be fine. Apparently not.

 

Waiting for the !RDY line to go low and *then* switching to the external oscillator seems to work. When the oscillator has a lock, its frequency is stable within a few PPB (ADEV @ tau 1s is around 4E-11) It also has the side benefit of allowing the flash to be updated without the oscillator connected.

 

So this is where I genuflect and say that you were right.

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

Glad you have it working.

 

As usual, finding the cause of the unexpected / undesired behavior is equally important as is finding a solution to the situation.

 

Only 4e-11 ?, Want to compare your rubidium clock to my cesium clock?

 

Oh wait, I don't own a Cesium clock... wink

 

JC

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

The ability to override the clock select fuses must have been added to the ATTIny841. This project was my first use of it, and I contemplated adding it to a project where I had used an ATTiny84, only to find there was no CCP or CLKCR register. That board is clocked externally (by one of my GPSDOs, not coincidently), and it's sometimes awkward to have to clock it while changing/updating the flash. My thought was to simply fuse it for the internal oscillator and then switch over at startup after enabling the watchdog. If it wasn't given an external clock, the watchdog would simply repeatedly reset it, returning the fuse settings, and giving the programmer a chance to take control.

 

It's kind of a wrench that you can't program an AVR that's fused for some external clock source without it being present. I do note that newer AVRs can be fused to use the internal RC as an emergency clock source. It seems to me that a far easier solution would have been to simply always use the divided internal RC oscillator when !RESET is low. That would make programming my crazy clock boards a lot faster (they use a 32 kHz crystal). But I guess it's just Monday morning quarterbacking at this point.