RA/RB/RC data after a WATCHDOG reset or MCLR
RonW
Posts: 39
SX28 documentation says that the value of the RA/RB/RC output ports remains unchanged by a watchdog reset or a MCLR reset.
However in testing I've done with two different SX-28's, either a watchdog reset or a MCLR reset caused the value of RC to change from $00 to $FF.
This code demonstrates the watchdog case:
DEVICE SX28L, OSC4MHZ, TURBO, STACKX, OPTIONX, BOR42, WATCHDOG
IRC_CAL IRC_4MHZ
FREQ 4_000_000
PROGRAM Start NOSTARTUP
Start:
TRIS_C = 0
IF STATUS.4 = 1 THEN
RC = 0
ENDIF
here:
GOTO here
On power-up, LEDs connected to port C are off. After a couple of seconds, a watchdog reset happens and the LEDs turn on.
This code demonstrates the MCLR case:
DEVICE SX28L, OSC4MHZ, TURBO, STACKX, OPTIONX, BOR42
IRC_CAL IRC_4MHZ
FREQ 4_000_000
PROGRAM Start NOSTARTUP
Start:
TRIS_C = 0
PAUSE 1000
RC = 0
here:
GOTO here
On power-up the LEDs are on for one second and then go off. When MCLR is grounded and released, the LEDs come on for one second and then go off.
I'm using the SX 28 Tech Board and the reset button on the board. The SX-Key is disconnected.
Has anyone else seen this? Is this issue documented somewhere? Am I missing something?
Thanks!
However in testing I've done with two different SX-28's, either a watchdog reset or a MCLR reset caused the value of RC to change from $00 to $FF.
This code demonstrates the watchdog case:
DEVICE SX28L, OSC4MHZ, TURBO, STACKX, OPTIONX, BOR42, WATCHDOG
IRC_CAL IRC_4MHZ
FREQ 4_000_000
PROGRAM Start NOSTARTUP
Start:
TRIS_C = 0
IF STATUS.4 = 1 THEN
RC = 0
ENDIF
here:
GOTO here
On power-up, LEDs connected to port C are off. After a couple of seconds, a watchdog reset happens and the LEDs turn on.
This code demonstrates the MCLR case:
DEVICE SX28L, OSC4MHZ, TURBO, STACKX, OPTIONX, BOR42
IRC_CAL IRC_4MHZ
FREQ 4_000_000
PROGRAM Start NOSTARTUP
Start:
TRIS_C = 0
PAUSE 1000
RC = 0
here:
GOTO here
On power-up the LEDs are on for one second and then go off. When MCLR is grounded and released, the LEDs come on for one second and then go off.
I'm using the SX 28 Tech Board and the reset button on the board. The SX-Key is disconnected.
Has anyone else seen this? Is this issue documented somewhere? Am I missing something?
Thanks!
Comments
What you are experiencing is the initialization of the port direction registers. On power up or reset, all port direction regsters turn the ports to inputs, eventhough the content of the outut registers themselves are unchanged. So if, after power up or reset you reconfigure the ports' input or output directions to the state prior to the reset, then the LEDs would show the state you previously had them in.
Cheers,
Peter (pjv)
If I understand you correctly, the TRIS_C = 0 at Start takes care of that. In fact, the LEDs connected to port C light up, indicating that the configuration register has been set back to output.
Ron
When the SX starts up or resets, the direction registers for each port (TRIS A/B/C if you like) are initialized to all ones, hence all inputs.
Cheers,
Peter (pjv)
Doesn't the first line in my code, TRIS_C = 0, change the direction register for port C to all ouputs after a reset? I know the port is set back to output after the reset because the LED's light up.
Ron
Sorry, I did not look at your code..... it is SX/B which I'm not familiar of the start-up details, and I improperly jumped to a conclusion on the source of your troubles. Someone with better SX/B skills than I have will need to answer you.
Sorry for any confusion I caused.
Cheers,
Peter (pjv)
No problem. I've looked at the start-up code the compiler generates. For my example, it's just
CLR FSR
JMP @Start
Have you seen cases where ports correctly maintained their data after a watchdog timeout or MCLR?
Thanks,
Ron
As I said earlier, the CONTENT of the output registers is maintained. It is the direction registers that get reset to input mode, so once they are again set to output mode, then the previous outupu CONTENT is displayed.
Cheers,
Peter (pjv)
I have done some experimenting with SASM - my results also show that on a MLCR reset, the contents of the I/O pins are NOT preserved.· As soon as the pins are set to OUTPUT (from the default INPUT at start), their output is high, regardless of what the state·they were·when the SX was reset.·
Of course, if the pin contents are defined in code before setting their direction, their output state is as defined.
Nate
I see your point. I tried it on my PDB and it does as you say.
After the TRIS_C is set to outputs, I would have expected the LEDs to go back to the state they where before the watchdog timed-out, but they don't they go to $FF ?
I can't explain it...
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheap used 4-digit LED display with driver IC·www.hc4led.com
Low power SD Data Logger www.sddatalogger.com
SX-Video Display Modules www.sxvm.com
"People who are willing to trade their freedom for·security deserve neither and will lose both." Benjamin Franklin
·
Thanks for confirming. I guess it's a case of the chip not quite performing as advertised in its datasheet. I wonder if it used to work, but something changed as the chip design evolved.
Thanks,
Ron
I tried an old Scenix SX28 I have, it works the same way as the new ones.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheap used 4-digit LED display with driver IC·www.hc4led.com
Low power SD Data Logger www.sddatalogger.com
SX-Video Display Modules www.sxvm.com
"People who are willing to trade their freedom for·security deserve neither and will lose both." Benjamin Franklin
·
I think it is good practice not to rely on any default register states after a reset. Therefore, in every application I write for the SX, I first initialize the port output registers, like MOV RA, #RA_INIT, etc. Next, I configure other port settings, like level, pull-up, etc., and finally configure the TRIS registers, i.e. define which pins are inputs and outputs. This way, you can be sure that the SX has the same port state after each reset.
I found out that some registers are even initialized differently when you reset the SX using the Debugger, or do a reset on a stand-alone system. For example, the FSR register is cleared on a debugger reset where it contains abitrary data when a stand-alone SX is reset. This once almost drove me nuts:
To clear all RAM locations, I copied and pasted the following code from another program:
ClearRAM
sb fsr.4
setb fsr.3
clr ind
ijnz fsr, ClearRAM
This worked fine when testing the application with the debugger but sometimes, the program ran into "Nirwana" when executed on a stand-alone SX. Why? Because I forgot to copy and paste the first very important instruction:
clr fsr
With the debugger, FSR was always automatically cleared but not on a stand-alone system. So in this case, some RAM locations were not cleared, and other parts of the code, relying on this did nit work as expected.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
to my experience, the RAM contents remains unchanged after a watchdog reset. This seems to be quite logical, as the RAM is static, and keeps its contents as long as it is powered. IOW, as long as power is appied to the SX w/o interruption, the RAM is fine. This also means that you should not rely on RAM contents in case of a brownout reset, as you can't tell how low the supply voltage has dropped.
I agree with you that there seems to be an error in the SX spec sheet concerning the port data. It is correct - and for safety reasons, it makes sense - that the TRIS registers all hold $FF after a reset to configure all port pins as inputs. Seems as if the port's output data registers are also initialized to $FF, although this is not logical. I'm currently populating another of my SX 28 MultiBoards for a new project. When I have it ready, I'll do some more tests on this issue, and let you know the results.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G