Shop OBEX P1 Docs P2 Docs Learn Events
P2 and IEC 60730 design standards — Parallax Forums

P2 and IEC 60730 design standards

jmgjmg Posts: 15,171
edited 2014-03-31 21:24 in Propeller 2
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 :
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

  • cgraceycgracey Posts: 14,134
    edited 2014-03-31 15:48
    The RESn input is asynchronous.

    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.
  • jmgjmg Posts: 15,171
    edited 2014-03-31 16:31
    cgracey wrote: »
    The RESn input is asynchronous.

    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 ?
  • cgraceycgracey Posts: 14,134
    edited 2014-03-31 19:36
    jmg wrote: »
    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.
  • jmgjmg Posts: 15,171
    edited 2014-03-31 19:58
    cgracey wrote: »
    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.
  • cgraceycgracey Posts: 14,134
    edited 2014-03-31 20:26
    jmg wrote: »
    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.
  • jmgjmg Posts: 15,171
    edited 2014-03-31 20:45
    cgracey wrote: »
    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.
    Sounds good.
    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 ?
    cgracey wrote: »
    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.

    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.
  • cgraceycgracey Posts: 14,134
    edited 2014-03-31 20:48
    Yes, I'll run the RC oscillator through the same type of divider and feed it into another empty pin input.
  • jmgjmg Posts: 15,171
    edited 2014-03-31 20:56
    cgracey wrote: »
    Yes, I'll run the RC oscillator through the same type of divider and feed it into another empty pin input.
    Sounds nice and flexible.

    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 ?
  • cgraceycgracey Posts: 14,134
    edited 2014-03-31 21:06
    jmg wrote: »
    Sounds nice and flexible.

    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.
  • jmgjmg Posts: 15,171
    edited 2014-03-31 21:24
    cgracey wrote: »
    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.
Sign In or Register to comment.