resetting sx in software
simon
Posts: 20
Hi!
I want to add a reset function to my sx project:
I plan to reset my sx when the user sends a special char over rs232.
How do i do a (soft) reset from my interrupt handler (receives the rs232 stuff) ?
jmp to a special location ?
Is it possible in software ?
Another solution might be a small transistor which puts mclr low for a short
time (maybe with a small cap on the basis to make the pulse long enough).
Would that work ?
Any other ideas ?
Bye, Simon
I want to add a reset function to my sx project:
I plan to reset my sx when the user sends a special char over rs232.
How do i do a (soft) reset from my interrupt handler (receives the rs232 stuff) ?
jmp to a special location ?
Is it possible in software ?
Another solution might be a small transistor which puts mclr low for a short
time (maybe with a small cap on the basis to make the pulse long enough).
Would that work ?
Any other ideas ?
Bye, Simon
Comments
I think I would use the transistor method, of course that will use an I/O pin.
Terry
in one of my applications, I have built in a similar feature where the SX shall reset after recognizing a break via RS-232.
Here is my trick: Activate the watchdog timer, and normally execute a clr !wdt often enough. When you want a reset, force the SX into an endless loop without executing a clr !wdt, and the watchdog does the reset for you.
Greetings,
G
@Terry:
Thats the problem. I guess that if i do a jmp within the interrupt handler
i will never get any interrupts again *g*
@Guenther:
That idea sounds cool !
I never thought about using the wdt for that
I will try that [noparse];)[/noparse]
Another idea might be to set a global variable RESET to 1
in the interrupt handler and to do a jmp in the main code
when the var is equal to 1.
Thank you for your tips [noparse];)[/noparse]
Bye, Simon
Terry
Later!
kenjj
although I have never tried it, I think is should work too: If you have a free port pin, connect it to the *MCLR pin. By default, this port pin is an input, i.e. high-Z, so it does not bother the *MCLR pin.
When you want to do a "software reset", configure this pin as an output at low level. This will reset the SX, thus re-configure this pin as an input again.
Greetings,
G
This is what i wanted to do with the transistor.
But your idea sounds better (=save one part [noparse];)[/noparse] ).
Is it no problem to the sx ? I will try that on the next prototype
i built [noparse];)[/noparse]
Thank you!
Bye, Simon
no, I don't think that it will harm the SX when you connect a port pin to the *MCLR pin, but you should make sure that the *MCLR pin is not "floating", i.e. you better also connect a resistor (4.7 kOhm would be fine) between *MCLR and Vdd.
BTW, the Ubicom datasheet recommends to add a serial resistor of 470 Ohms between *MCLR and any other external components to protect this input against over-current.
I have added a schematic showing the reset circuit I normally use, plus the "software reset" connection to RC7 as an example.
Greetings,
G
Thanks for your graphic [noparse];)[/noparse]
On my current layout i only use a 1KOhm
resistor to +5V on mclr and a small swith to connect
mclr to gnd (=manual reset).
The 470 Ohm resistor sounds like a good idea [noparse];)[/noparse]
What is the diode for in your Layout ?
Bye, Simon
some explanation:
When the SX is powered up, C8 is discharged, thus pulling low the *MCLR pin. Then, C8 is going to be charged via R9 at a time-constant of 4.7 ms, i.e. the *MCLR pin is forced to low level for a "while". When the voltage across C8 is large enough, the SX "sees" high level at *MCLR, i.e. it ends its reset state.
The diode is there to discharge C8 via the power supply in case power is turned off, in order to have an "empty" C8 available as soon as power is turned on again.
BTW: Your switch for the manual reset could still remain in place, and the 1kOhm to +5V is fine as well.
Greetings,
G
Thanks for your explanation!
You are using this as an external reset on power on
instead of the internal power-on-reset feature [noparse];)[/noparse]
For me the internal reset works fine right now.
But if i get any trouble i know what to do now.
Thanks [noparse];)[/noparse]
But if you use this circuit with the "software" reset
using portc.7 the current might be to much, or am i wrong ?
If you set PORTC.7 to low the capacitor gets discharged
immediately and might cause a current >30mA.
Bye, Simon
yes, you are right, when using the circuit I suggested, it can happen that RC.7 has to sink more than 30 mA for a short while. Therefore, as a safety measure, it makes sense to add a resistor (say 180 Ohm) between RC.7 and *MCLR.
On the other hand, during many experiments with the SX, preparing my book and working on other projects, I never killed an SX output by too much current even though it sometimes happened that outputs were shortened to Vdd or Vss, ort offending outputs were connected together. It seems as if the SX output drivers have some built-in over-current protection, but don't take this for granted. The Ubicom Datasheets do not mention such a feature.
In my designs, I usually add the components for an external power on reset to make sure that the SX resets properly when the supply voltage rises very slowly, but in most cases, the internal reset works fine.
BTW: I already published this in the former SXList a while ago:
When developing one of my projects, I had real trouble getting the SX correctly start up, and I assumed for quite a while that it was a power-on reset problem. So I tried to use the external reset components as shown in my drawing, but they did not fix my problem. I also tried an external reset controller whithout success. I then did the "watchdog trick", i.e. at the beginning of the main program, I checked the PD flag for power-on, and went into an endless loop after activating the watchdog timer in order to force another reset. This cured the problem, but it took me a while to figure out the real reason for that problem.
In almost all of my SX programs, I insert code the clear all RAM locations at startup like this:
···· clr fsr
ClearRAM
···· sb······ fsr.4················ ; Are we on low half of bank?
······ setb· fsr.3················ ; If so, don't touch regs 0-7
···· clr······ ind·················· ; Clear using indirect addressing
···· ijnz····· fsr, ClearRAM···· ; Repeat until done
When writing the code for the application, I used the "Copy & Paste" feature to copy these instructions into the new source code from another program, but by mistake, I did not copy the initial "clr fsr" instruction. This was really a "killer"! Obviously, the fsr is not automatically initialized to zero at power-on, but it holds some arbitrary value. This caused the ClearRAM code to "go nuts", and made me believe that the SX had a reset problem. But - as usual - the real problem was "between the headphones".
BTW: When debugging the code with SX-Key, it never failed because the debugger seems to automatically clear the FSR. This is why it took me a while to find that bug.
Greetings,
Günther
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Today i tried the reset method. Its working [noparse]:D[/noparse]
Hardware:
MCLR o-------[noparse][[/noparse]_470ohm_]--------+-----------[noparse][[/noparse]_1KOhm_]-----o +5V PORTC.4 o-------------------------+ __v__ | GND o----------o o----------+initcode:
the code for a reset is:
Make sure NOT to set PORTC.4 as output and to 1.
If you do so and someone presses the reset button
it produces a short circuit.
Bye, Simon
this is a nice, simple design. I think, you even could protect PORTC.4 in case it ouputs 1 by inserting another 470 Ohm resistor between PORTC.4, and the rest of the world. In this case, you might consider increasing the value of the resistor between +5V and PORTC.4 from 1 kOhm to 4.7 kOhm.
Greetings, G