Brownout reset behavior and timing?

Phil Pilgrim (PhiPi)

The Propeller data sheet said...

RESn: Brown Out Enable (active low). Must be connected to either VDD or VSS. If low, RESn becomes a weak output (delivering VDD through 5 k&#937[noparse];)[/noparse] for monitoring purposes but can still be driven low to cause reset. If high, RESn is CMOS input with Schmitt Trigger.
...

Shutdown mode is triggered by one of the three following events:

1. VDD falling below the brown-out threshold (~2.7 VDC), when the brown out circuit is enabled ...

This would seem to imply that when BOEn is tied low, and when Vdd drops below 2.7V (or thereabouts), that RESn is pulled low by the Propeller itself (for "monitoring" purposes). Is that what it means? I don't know; it doesn't actually say so explicitly. If my inference is correct, though, what's needed is a timing diagram that looks like this:



It would answer several questions necessary for a design-in, such as:

1. How wide is the brownout voltage hysteresis band (if any)? What are the max and min values of its high and low thresholds?

2. How much current can RESn sink?

3. Does RESn pulse low during a software reset?

4. What is the Vdd dropout voltage below which RESn quits sinking current?

5. How long is the delay, if any, between Vdd going below the lower hysteresis threshold and RESn being pulled low?

6. How long is the delay, if any, from the time Vdd goes above the upper hysteresis threshold and RESn returning high?

These are the kind of details that every IC company puts in their datasheets. It's been more than 3½ years since the Propeller was introduced, and it disappoints me somewhat that parameters such as these have not yet been characterized for publication — or even adequately explained. Sorry guys, but you've still got some backfilling to do before the Prop II is introduced.

-Phil

Update: 'Modified the timing diagram to include a query about the dropout level and added questions 2, 3, and 4. Normally, after quiet reflection, I would have made further edits to moderate my somewhat peevish tone. But since others have already read and questioned it, I guess it has to stay and be dealt with separately.

Post Edited (Phil Pilgrim (PhiPi)) : 9/19/2009 9:39:15 PM GMT

T Chap

Backfilling is on an 'as needed' basis.

Or as in the south we used to say 'squeekie wheel gets the grease'.

But there was an counter saying to the squeekie wheel saying which was 'don't make a mountain out of a mole hill'.

But the most classic phrase is 'how's ya momma 'en nem?'

Hope this helps.

Javalin

Phil

Another interesting post.

>but you've still got some backfilling to do before the Prop II is introduced.
Should we read anything into this? And other other posts you've been writing recently?



James

Phil Pilgrim (PhiPi)

Javalin said...
Should we read anything into this?

Aside from my being in a grumpy mood when I wrote it? No. However, I do think some important detail work has been left behind in the dust of a headlong rush to the Next Big Thing. Not that I don't understand it or sympathize with it. I hate writing and would much rather be designing something new than documenting something old. Also, I know that I will eventually get the answers I need from the Forum. But an OEM who's evaluating the Propeller in competition with other micros for a million-piece design-in may not be so patient or understanding and may misunderstand sketchiness in the data sheet (compared with those from, say, Microchip or Atmel) as symptomatic of deeper issues. Now we know this is not the case, but they might not. Hence my somewhat peevish (but nonethless well-intentioned) prod — because I know that if the Propeller succeeds in the larger OEM market, we all benefit.

But that's a distraction from my primary reason for posting, which was to get confirmation that RESn will actually sink current on its own when Vdd is below the brownout level and/or during a software reset (the answer to which bears on a rather large project in its own right). But this raised a bunch of other questions regarding the limits of this behavior, none of which are documented AFAIK.

-Phil

Post Edited (Phil Pilgrim (PhiPi)) : 9/19/2009 9:40:27 PM GMT

Phil Pilgrim (PhiPi)

I've been doing some sleuthing on my own and can answer some of my own questions. Here are some scope traces taken with various pullup loads on RESn:







These confirm the main point, namely that RESn is pulled low by the Propeller itself. They also answer the following quesitons:

2. How much current can RESn sink? Not much! The RESn output would have to be buffered to be useful.

4. What is the Vdd dropout voltage below which RESn quits sinking current? About 0.66V.

Now, you may think this answers some of the questions about voltage trip levels and delays. Just looking at the traces, one might conclude that the lower brownout threshold is 2.0V and that there is no delay. I don't think this is correct, though. I'm more inclined to believe the lower level is higher than that and that there is a delay built-in. But I will need much better control over Vdd than I have now to verify this.

More to come!

-Phil

Tracy Allen

Phil,

I'd interpret the phrase, "delivering Vdd through 5 kOhms", to mean that the 5 kOhms is in series between the output of the internal brownout detector and the pin and that there is a direct connection from the pin to the internal reset circuit.

RESn pin  -------------o----------------- internal reset circuit
                                |
                                |       5kOhms
                                `------/\/\--------brownout detector

In normal operation the brownout output connects to Vdd, and in brownout connects to Vss, so ithe pullup or pulldown is 5k either way. Your result is not too inconsistent with that, given that the resistor is probably(?) polysilicon and nonlinear with voltage.

With respect to the hold time,

[b][i]The Propeller data sheet said...[/b][/i]
Upon power-up, or reset:  1.  The Propeller chip’s internal RC oscillator begins running at 20 kHz, then after a 50 ms reset delay, switches to 12 MHz. Then the first processor (Cog 0) loads and runs the built-in Boot Loader program.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Phil Pilgrim (PhiPi)

Tracy,

Yeah, I think you're right about the 5K being in series between the BOD and RESn pin. It's rather curious that the datasheet doesn't just say, "delivering the brownout detector's output through 5KΩ," since "delivering Vdd" would seem to imply an internal pullup. The series connection makes the most sense, though, because it protects the pin from external reset circuits that might drive the pin high as well as low.

-Phil

Phil Pilgrim (PhiPi)

My next experiment was to vary Vdd very slowly up and down to determine whether there is any hysteresis in the brownout threshold. Apparently not, since I was able to get RESn to oscillate around 2.74V. But that gave me a setting for my scope trigger so I could determine what the delays are. Here are the two traces. This one is for power down,



and this one is for power up.



Based on these observations, I am able to produce the following timing diagram for one Propeller chip only:



The remaining thing to determine is whether a software reset affects the RESn out. I'm betting that it does not.

-Phil

Post Edited (Phil Pilgrim (PhiPi)) : 9/20/2009 3:57:43 AM GMT

Phil Pilgrim (PhiPi)

For my final experiment, I attached a 5.1K pullup to A0 and loaded the following program into EEPROM:

[b]CON[/b]

   [b]_clkmode[/b]     = [b]xtal1[/b] + [b]pll16x[/b]
   [b]_xinfreq[/b]     = 5_000_000

[b]PUB[/b] start

  [b]dira[/b][noparse][[/noparse]*0]~~
  reboot

I was able to see negative-going pulses on A0, which verified that the chip was indeed rebooting periodically; but, as expected, there was no activity on RESn.

This concludes my experiments and answers my original questions (except for chip-to-chip variations over temperature). Hopefully, Parallax will take the time to characterize these parameters more fully, so that they can appear in the data sheet, along with a clearer explanation of how the brownout reset works.

For now, though, I have enough information to proceed with my project.

-Phil

dMajo

Phil:

3)·No
5,6) I suspect that RESn is pulled·low/high·directly by the output of the voltage comparator.·Probably it is delayed by some propagation delays. The·brown-out is·just one of the inputs of the reset circutry and the only that is mirrored out to the RESn. It will be nice if the PropII will have this improved by sending forth the inside reset state (logical·and of all reset·sources)


I had some clarifications by Chip·(some time ago)·regarding this.

Extract·
Dario,

Yes, you may control BOEn from the CPLD. When BOEn is high, though, there is no pull-up on RESn, so you might need to add a pull-up.

Chip

P.S. There is a possibility that when BOEn is lowered, the internal brown-out detector may output a positive state before it fully powers up. This could cause a reset, but I'm not sure. You'll have to do some experimentation.

Just one question more:

1)May I connect the BOEn to the CPLD to make it software configurable?
2)Do I need any pull up/down? What happens if it is left floating (this will happen for sure for some 10 millisecond during the cpld startup when all the pins are HiZ)?

Many thanks

Dario,

If BOEn=VDD, the brown-out detector will be disabled and RESn will be a high-impeadance schmitt trigger input (no internal pull-up).

If BOEn=VSS, the brown-out detector will be·enabled and RESn will have a pull-up while no brown-out condition is occuring, or a pull-down while a brown condition IS occuring. The pin is also always a schmitt trigger input that, when driven low, will hold the chip in reset, regardless of brown-out status.

There are two internal sources of reset, neither of which can be observed on RESn externally: power-on reset and software-induced reset.

So, yes, you can monitor RESn while BOEn=VSS to observe any brown-out condition, and you can also drive it low to force a reset. However, you won't be able to tell when a power-on or software-induced reset occur.

Chip

Dear Chip,

I hope I'm not stealing too much time from your propii development, but I need urgently some clarifications:

Have I understood correctly the datasheet regarding the BOEn, RESn pins description?
RESn will be wired to cpld. Cpld pin can act as open drain/collector output and input.

• If BOEn is enabled (low) then there is no need for RESn pull-up because of it's internal (5K)? I can reset the prop from cpld by taking it low.
• If I switch the cpld pin to input can I recognize (by monitoring RESn) that prop power went below the threshold or internal (software) reset was issued to the prop

Best regards
Dario

PS. I have read some threads on this but I haven't found a clean answer. I have the prop booting from a spi flash on cpld startup. I want to detect prop software reset to bring the cpld back in spi to i2c eeprom emulation.

Regarding my needs I came to the conclusion that the "software reset" for me will become a shutdown command, because after the reboot the prop will not found the boot eeprom nor the PC thus shutting down. For this reason I have made an cpld driven software reset (you have to set a bit in the cpld register) and a wake-up timer that takes out the prop from the shutdown_mode (internal software reset).


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· Propeller Object Exchange (last Publications / Updates)

Agent420

>But an OEM who's evaluating the Propeller in competition with other micros for a million-piece design-in may not be so patient or understanding and may misunderstand sketchiness in the data sheet (compared with those from, say, Microchip or Atmel) as symptomatic of deeper issues.

Not that I have any oem experience, but I would think that is a good point.· And I find it a bit curious, because it seems like the oem market would be a natural target for a custom silicon product that must have required great resources to develop; yet there are a few things in my mind that seem to suggest that is not a big goal for Parallax (another being no code protection).

But as for the technical documentation, given the Prop was such a hands-on effort, you'd think they'd have most of that kind of information at their fingertips.· And the people involved would very likely be familiar with what a 'commercial' datasheet looks like.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔