Minimum "Low" Time for Resetting via MCLR?

Zoot

I've got a few projects where an SX may use a peripheral SX and have access to \MCLR so the "host" SX can do a hard reset on the peripheral at will. Nowhere in the datasheet for the SX28, nor the SX-Key Manual could I found a min/typ low time for initiating a reset. ???

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php

RobotWorkshop

Hello,

Since it isn't posted one thing that may help is to look up the datasheet for one of the regular reset chips. The Dallas DS1233 is one example. It should be fairly conservative in terms of timing so if you emulate that with the SX you should be in good shape.

Good luck,

Robert

MikeK

If it helps any, the time for PIC16Fxxx seems to be around 2us (minimum TmcL).

LoopyByteloose

It might help to think in terms of clock cycles rather than microseconds. PICs are generally 4x slower than SXes and even they should be thought of in terms of the clock rather than the period of time. If you reread the SX28 documentation with that in mind, I suspect you'll find the answer.

Obviously, it can never be less than one clock cycle unless it is sensing the transition edge as the signal would be occasionally missed. One clue is the mentin that the input is a Schmitt Trigger and needs a 10k pullup to stablize it. But, there might be a rationale to double or quadruple that. This would likely be the case when registers are being saved for orderly shut down, like a sleep mode.

In addition to the recognition of the signal, there is a stablization period from a hard reset. This is usually much longer. I looked at pages 39-40 of the SX-48 document and the restart cycle time is adjustible in Fuse registers from .25ms to 1sec.

So the questions remain of how it is sensed, polled,and managed.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PLEASE CONSIDER the following:

Do you want a quickly operational black box solution or the knowledge included therein?······

···················· Tropically,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan

Post Edited (Kramer) : 2/5/2008 12:54:45 PM GMT

Guenther Daubach

Hi all,

When you study the description of the reset mechanism in the SX28 datasheet (page 27), you will notice that the reset circuitry has its own DRT start-up timer which is independent of the system clock. IOW, the system clock does not have any influence on the reset timing.

Zoot wants to reset an SX via the /MCLR input from another host SX, so we can assume that the power supply is stable, i.e. we don't talk about a power-on reset here. When a falling edge occurs on the /MCLR input, the reset latch is set, so it brings and holds the SX in the reset state. When /MCLR goes high again, the DRT timer starts running, and after a delay of approx. 72 ms, the reset latch is cleared again which ends the reset state.

IMO, the low time on the /MCLR can be really short (1µs or even less) as the reset is triggered by the falling edge on /MCLR, and not by the length of the low state. Much more important is that the host system must allow the peripheral SX to return from the reset AFTER is has set /MCLR high again for at least 72 ms. IOW, the host can't expect to perform any valid communication with the peripheral SX until this time has elapsed. Assuming a host system clocked at 50 MHz, this means it has to wait at least 3,600,000 (3.6 Million) clock cycles before the peripheral is ready again!

It might be an idea to connect an output from the subsystem to an input of the host system with a pull-up resistor which is cleared by the subsystem after it has performed the reset, and the typical initialization stuff to "tell" the host when it is ready. The host can poll this status line after it has issued a reset until the subsystem reports that it is ready.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,

Günther

Zoot

Thanks, all.

In this case, the SX will "emulate" Stamp times -- so it will wait after performing a hard reset on the peripheral. And it would only do that in the case of communication failure (e.g., timeout after waiting for response via serial).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php

Post Edited (Zoot) : 2/5/2008 6:23:08 PM GMT

Bean

Using the SX to reset itself it seems that /MCLR must be low for about 100nSec.
Unless something funny happens when the SX lowers it's own /MCLR pin.

' Reset test
' If the low pulse on RB.0 resets the chip, you will get slow blinks on LED
' If the low pulse on RB.0 does NOT reset the chip, you will get one slow blink, then fast blinks
 
DEVICE SX28, OSCHS3, TURBO, OPTIONX, STACKX
FREQ 50_000_000
 
LED       PIN RA.3 OUTPUT
' Connect RB.0 to /MCLR pin
 
PROGRAM Start
 
Start:
  HIGH RB.0
  LED = 1
  PAUSE 1000
  LED = 0
  PAUSE 1000
  RB.0 = 0
  NOP
  NOP
  NOP
'NOP   ' Without these two NOPs the SX doesn't get reset, with them it does get reset
'NOP
  RB.0 = 1
  DO
    LED = ~LED
    PAUSE 100
  LOOP
END

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
www.iElectronicDesigns.com

·

Zoot

Bean, that's a pretty clever test harness. And I kinda like the idea of a chip that resets itself

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php

Guenther Daubach

Bean,

this is a great trick to figure out the minimum reset pulse length, and it also shows that it's possible to let an SX reset itself. I think there was a question about this in the forum a long time ago.

BTW: Another method to let an SX reset itself is using the watchdog timer. With the watchdog active, force program execution into an endless loop without clearing !WDT. The watchdog will then reset the chip after it has timed out.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,

G

Chris Savage

G

LoopyByteloose

I was pondering where the 72ms comes from. FYI, I located the older SX-Ubicom PDF - Ubicom SX Family User's Manual Ver 3.1 which explains this. Previously, it seemed to me that this period defaulted to something like 28ms.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PLEASE CONSIDER the following:

Do you want a quickly operational black box solution or the knowledge included therein?······

···················· Tropically,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan