Reset: Data sheet - part III
In Data sheet - part II one of the comments asked a questions about the /MCLR function on the SX. I answered the question in the comments of that post, but we should explore the reset function a little further.
Open up your SX20/SX28 data sheet and turn with me to page 30. Just prior to this page is a detailed explanation on the reset circuit. We can read that later, but on page 30 we see a table. This table is titled “REGISTER STATES UPON DIFFERENT RESET OPERATIONS” and it shows that there are five different ways the SX can be reset. Each way is triggered by a different path and each way leaves the internal registers of the SX in a particular state. This is important to remember as you get deeper into the SX and its software.
The wakeup reset is slightly different from the other four reset options. The Power-On, Brown-Out, Watchdog Timer, and MCLR all initialize the chip to start the code execution over. The wakeup is slightly different and continues execution where the program left off last. The wakeup is commonly used to put the SX “asleep” to save battery and processing. I need to read more myself before I can explain this further.
How about a brief description of each reset:
- Power-On: As the name suggests the reset condition when the device is first powered on. The MCU is kept off until the voltage crosses a certain threshold and is stable.
- Wakeup: This reset condition is usually caused by an external event to cause the MCU to stop “sleeping” and to start processing again.
- Brown-Out: If your Vdd supply voltage (+5 or +3.3) dips below a threshold the MCU will turn off to ensure it does not create erratic output. A dip in the Vdd could be from low batteries or from motors turning on and off.
- Watchdog Timer: This reset is a good option in critical systems where you must ensure that the chip is operating at all times. What I mean is you can set a timer in the MCU. If the timer expires before the software gets around to servicing the timer, then the MCU resets. This can help to ensure the MCU doesn’t lock up or get stuck processing one thing when it should be doing another task.
- MCLR: This reset is similar to the Power-On and Brown Out, but this reset is often caused by a user or some other external event. The circuitry inside the chip for Power-On, Brown-Out and MCLR is similar.
OK - now go ahead and read page 28 and 29 if you haven’t. The description is a little technical if you are not familiar with electronics. The basic thing to understand though is that the instant you apply power to a system the MCU isn’t on yet. There is a slight delay, very small, that keeps the MCU off until the Vdd has stabilized.
That is about enough of an overview of the reset for now.
July 18th, 2008 at 10:00 pm
Timothy,
This is very good info. I think I actually got more out of pages 28 and 29 (meaning I understood more of what it was saying).
I have to ask some very basic questions about the chart on page 30. I understand that it is showing us the state of each register (like a little box with info in it) at each of the reset types (5 types in all). Some registers are FFh and some are 0Fh (is this low or high, 0 or 1, on or off - I assume so, but it is a guess). Some are undefined, meaning we might not know what the state is. Others are partially known and partially undefined. The condition of all is determined by the method of reset. Is that basically correct?
As regards page 30 (though I don’t understand many things), it looks like the variation in register states is very slight (although particular for each reset). I couldn’t really figure it out, but did notice that at power-on and brown out - more registers are undefined. This makes sense. Other resets (wake-up, watchdog timer, and MCLR either leave particular registers(the ones undefined in Power-on or brown out)in their current state or redefine them to a particular state. And therefore, at the power-on or brown out resets, some registers may have an undetermined state. This would mean (I think) that they would need to be set at a paticular state (in order to know for sure what was in them).
Am I even close?
July 18th, 2008 at 10:09 pm
FFh and 0Fh are the states of the bits in the register. The “h” is telling us the “FF” or “0F” is in hexidecimal. Two hexidecimal numbers make means it is eight bits. I haven’t covered hexidecimal in a post, but it is couting with a base 16. So we count 0,1,2,3….9,A,B,C,D,E,F. You probably know this Whit from your other programming, maybe others don’t. So the FF can be decoded to binary as “11111111″ or 0F is 00001111.
It is imporant that the table on page 30 define each state if it is known or not known. When you are writing programs in SX/B or SASM or C you need to understand how the registers could get modified. You wouldn’t want to have your program store a value in a register that could get corrupted or assume a value exists in a register at startup after a reset condition occurs unless you are certain you know what that it can persist.
It is very important that your program defines registers and states and assume very little. A program will be more robust in this regard, but that is a whole other text book!
July 19th, 2008 at 4:58 am
It is best not to assume I know something too well. As I looked through the rest of the data sheet, I thought the FFh and OFh might be hexidecimal numbers. I am familiar, but certainly do not use it much and would have to refesh myself it I was using it often. If you told me to convert FF to a binary number, I probably could have done it, but I would have had to think it through for a while. The last time I fooled with it in any detail was in while back.
But, just to show the gaps in my knowledge, learning that the “h” told me to read FF and 0F as hexidecimal numbers was something I had long forgotten (if I ever knew it).
July 19th, 2008 at 5:01 am
Just another note to say thanks for doing this for beginners to the SX. This is a mysterious process to those of us who have not fooled with it much!