P2 and IEC 60730 design standards
jmg
Posts: 15,148
I think this needs its own thread, as there could be some simple coverages possible here.
IEC 60730 is a design standard, that covers mainly safe modes of failure, and tries to avoid single point failures
examples
http://am.renesas.com/applications/a...30-1_child.jsp
and IEC 60730 also shows in Micros in areas like this :
other micros have Async Port reset, and that allows an external watchdog to at least drive pins to a known state should 'normal transmission' cease.
Is the P2 Pin reset Async ?
Can the RC osc's (& xtal?) be used to 'reality check' each other, and the PLL ?
What about partial failure modes, like say, a PLL that has run to Ceiling - some of the die may still clock ok, some may not ?
IEC 60730 is a design standard, that covers mainly safe modes of failure, and tries to avoid single point failures
examples
http://am.renesas.com/applications/a...30-1_child.jsp
and IEC 60730 also shows in Micros in areas like this :
The MSP430 has
Oscillator fault Note: Oscillator fault
The oscillator fault is maskable by an individual enable bit OFIE. It is not disabled during a general interrupt enable (GIE) reset.
other micros have Async Port reset, and that allows an external watchdog to at least drive pins to a known state should 'normal transmission' cease.
Is the P2 Pin reset Async ?
Can the RC osc's (& xtal?) be used to 'reality check' each other, and the PLL ?
What about partial failure modes, like say, a PLL that has run to Ceiling - some of the die may still clock ok, some may not ?
Comments
After a reset, the chip starts up using the internal RC oscillator.
There is no way to test the PLL or crystal oscillator before switching to them.
Is there a PLL-Locked flag, so that part of the operation can be verified ?
On the crystal, if the Osc-output could be aliased as a mappable pin, that could allow means to check Xtal=ok from RC osc, before mode change ?
There is no PLL-locked flag. There is no way to verify that anything works before switching. It could be done, of course, with a little extra hardware.
Sounds well worth looking into, given the growing importance of standards like IEC 60730 and the emphasis on self-checking.
Such verify steps could also speed time from reset.
Mapping Crystal Schmitt buffer to a readable pin# should be minimal cost ?
PLL Lock may have an existing logic node, that can map to a register ?
I've seen some clever things done with CtrPLL, and knowing the PLL was or was not, locked, could help further tune those.
I think I'll put an 8-stage cascaded divider after both the crystal oscillator and the PLL and then feed them into the empty pin inputs for pin 95 and pin 94. This would be in the pad frame.
Thanks for bringing this up. I've thought that it would be good to be able to know if your crystal is actually running, or not. The PLL is a little silly to check, because it's on the die, along with everything else. You might as well retest the ALU on every power-up.
That should also mean Counters can calibrate the RC osc, as well as verify Xtal is operating, which opens up more dual timebase options.
Can the RC osc also map to an empty PIN, so once the Xtal is enabled, the RC osc is still visible ?
Yes and no.
PLL's are analog in nature - so there are disturbance and setting/settling cases that a Lock, or freqCheck can cover.
( plus I understand the present P1 has distinct PLL failure modes).
A design that varies PLL multiplys to save power, might want to know it is in-range, before enabling PLL as sysCLK.
An 8 stage ripple counter has appeal.
Some systems designs do retest the ALU on every power-up, and the P2 will allow a thread to do that type of test, live.
I can see quite a lot of instances where one thread is a 'SW watchdog' in nature.
It can do quite a lot of self checking, and then use a SW reset, or an external watchdog, to cover 'not right' cases, and a graceful retry/fail/limp can result.
Does the RC osc continue to run when Xtal or PLL is selected, or does it have a separate SW Enable bit ?
( Some micros can disable the RC osc & PLLs to save small amounts of power.)
If someone ran a P2 to some pgm point, (valid idle pin states) then [externaly] froze the XtlaI (not in PLL mode?), what Icc would result ?
The RC oscillator continues to run, but at ~20KHz, when the crystal oscillator or PLL are selected.
If the crystal input were frozen and it was the selected clock source, you would only have leakage current, which would probably be about 1ma.
So the 20KHz is not likely to be much of a contributor to externally-halted minimums.
To clarify, the FastRC (20MHz?) is used to Boot, and then XtalOSC is user-enabled, but the FastRC continues until the fSys source is changed, at which time the FastRC changes to SlowRC ?
I think this allows
* FastRC Freq can reverse-check by reading the Xtal-pin-Divider path (Xtal OSC = On, not enabled as CLK source)
( I guess that Xtal-pin could be Mains, or 32KHz RTC pulses, it does not have to be MHz based)
* SlowRC can be used as 2nd Osc when SysCLK is Xtal or PLL, for 'seed' or watchdog tasks (temperature sense?)
Does that need two dividers, or is the 'mode' of the RC_Osc effectively flipped.
A single divider would need user pause on changes, to flush counts from the other frequency.