Incorrect wakeup - WKPND_B ?
Digital1010
Posts: 8
This is the 1st time I have used the SX in any developments. So with that, maybe I have mis-interpeted or just missed the information that explains the issue that I am having.
History:I have a complex data acquisition system that was designed in-house of which draws too much power even in it's sleep mode to leave for extended times in a vehicle. I added a simple design change which uses the SX28 at the front end to control the power to the rest of the system. It communicates with the DAQ to power down and also what woke it up. I also use 7 lines of the SX RB ports as edge wakeup lines. These are vehicle monitors. The unit always wakes just fine no matter which line requested it. I use the WKPND_B register to determine what line woke me up and send that info to the DAQ.
Problem:The problem is the WKPND_B is incorrect. What I found was if I set it for all H 2 L edges and the lines were being held high, the WKPND byte is correct. If I set all for L 2 H edges with pulldowns, all of the bits get set in the WKPND byte. The hardware configuration that I have(need) is RB.0-1 H2L with pullup on these lines and RB.2-6 L2H with pulldowns on those lines. The WKPND_B will give me a truth table for wakeup as follows:
RB.0 01111101
RB.1 01111110
RB.2 01111100
RB.3 01111100
RB.4 01111100
RB.5 01111100
RB.6 01111100
Again, if you set it up with all H2L edges with pullups, the truth table will be correct.
RB.0 00000001
RB.1 00000010
RB.2 00000100
RB.3 00001000
RB.4 00010000
RB.5 00100000
RB.6 01000000
HELP!· I've attached a piece of the code that doesn't work.· Idea's anyone?
Comments
I did not go through your code but to my own experience, it is important to give the WKPND bits a "clean start" at power-on reset. I.e. after configuring the ports, and the wake-up edges, execute a
mode $09
clr w
mov !rb, w
sequence to clear all WKPNDB bits that might have been set due to transitions on the port B pins during power-up.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
From my recollection, I had to do some testing to determine how the pins cycle on wakeup, and I determined that I could not rely on the WKPND_B register to tell where my wakeup came from. I ended up doing a hardware redesign, to force one of my pins to hold the logic state they had before wakeup, so that I could determine the status of pins·after wakeup.
I remember it being a screwey situation, and·I had to·pound the datasheets hard·and write some test code to determine what was going on. Long story short, my solution ended up being hardware...
Also, sorry I don't have my notes here to remember exactly what was going on....·· ...I will try to look at them·and get back to you if I have a chance next week.
-Dan
·
I agree with Dkemppai. I have searched the data sheets and I don't think it works the way it is portrayed. Since my hardware design is already implemented, I'm thinking about not putting it to sleep, running at 32khz and just using the edge mode and trying to mask the bits to capture which line requests the DAQ system. I can do that with approx. 8-9ma as to the origianal 3ma with sleep mode.
If anyone does see how to make it work the right way............
Dropping the system voltage will help the to lower the power a lot...
Good luck!
-Dan
P.S. Parallax, If you guys ever get a chance, It would really be really nice to see·FAQs and some example code for low power sleep mode operation. Wakeup on edge detect (rising and falling), and how to implement such·a wakeup correctly, etc.·(In ASM, and SX/B·of course [noparse]:)[/noparse]
·
Thanks and I'll keep watch for a sleep fix. I can't believe we're the only ones that have encountered this problem and I can't change hardware at this time $$$$$ for board changes and production runs
quick and easy.
My device was a minature low power device that needed a lot of processing power at intermittent invervals, so the SX was a good fit. I just wish I could have utilized the wkpnd to determine the source.
-Dan
GG
edit: that 18 msec wake up is independent of the processor osc speed for the SX28.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Bad spellers of the world untie!
You would be correct in that the pull up resistors are external. And you are correct regarding the examples shown in 4.4. I have used those examples and they work. The problem is the example only does a "High to Low" and not a "Low to High" and if you only look a single bit that you are toggling, you will think everything is great, however if you look at the truth table in my 1st message, no matter which wake up I toggle, all of the L2H lines (RB2-6) show up as if they have been toggled (I physically monitored RB0-6 with a Yokogawa DL7480.. They are not toggling!). As far as the wakeup time, that is not a problem, I only need to know what woke the unit up so that I can record that. Timing is not that critical there(with in reason). Just as a reference I did a simple circuit on the SX proto board with simple pullups on RB0-1 and pulldowns on RB2-6. No other components to possibly influence in any other way and I still get the same truth table from the WK_PND_B
I may be programming it wrong but I have tried every way and every example that I can find with no luck all though I tend to be a Harware guy, not software.
You can always invert the input before it reaches the SX, but you mentioned you're locked into your hardware already.
The good news is (according to a recent TV commercial) this is where I should say, " but I saved a boat load of money on my car insurance by going with Geico......
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Bad spellers of the world untie!
But not--Upon port B wakeup from SLEEP, the bits configured to detect LOW to HIGH transitions were all set in wkpdn_b, no matter which bit actually caused the wakeup. Bits configured to detect HIGH to LOW transitions worked as expected, and retained good information about which bit caused the wakeup/interrupt. As in your truth table. And without SLEEP, both edges retained good information.
Weird.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
As Digital1010 observed, the pins rb0 to rb3 all cause wakeup just fine, no matter which edge is configured. The unexpected aspect of this is the effect low to high transitions have on the individual bits in wkpnd_b. I had not noticed that before. I've only dealt with 1->0 transitions, which work as expected.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
This illustrates the "bug" in question in another way. Suppose the 4 inputs are all active low with pullups. That works fine when you press and release one button at a time. The program wakes on either edge, and the wkpnd register comes back with the correct bit set for the button pressed.
However, if you press and hold down one of the buttons (state=low), while you press and release a second button, things get dicey. Wake up happens as it should, but the wkpnd register continues to hold a 1 in the bit for the first button, even though its state has not changed. Wkpnd also shows the bit corresponding to the second button, the one that really did cause the wakeup. But the program can't sort out from wkpnd alone which pin caused the wakeup. If you then release the first button (state=high), wkpnd will still show its bit, as it should, and you have to press a different button before the first button's wkpnd bit will return to zero.
So, in summary, any input that is low at wakeup causes its corresponding wkpnd bit to be set high, even if there was no edge on that input.
It can be sorted out by looking at the current contents of rb and comparing with the past contents, provided the high and low states are long enough in duration. If the inputs are short pulses, and you can't rewire the board, maybe a capacitor for pulse stretching could be hacked in.
I don't know any secret way around this. I agree it needs to be better documented.
The wakeup is very sensitive to noise and contact bounce. Best use schmitt trigger input configurations, and good RC debounce.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Just hit your web site, Very nice!!
Could this be causing your problems? Save your list of pending triggers before re-init of the ports.
You have also enabled wakeup on an output pin, rb.4. This may cause problems as above.
You probably also want to turn on the internal pullups for the input pins, just to be safe.
BTW, if you ever turn on those interupts, you are going to have contention within your serial output code.
I hope this helps,
-AGM-
Post Edited (Andrew G. Miller) : 2/4/2006 12:21:33 AM GMT
I believe that parallax needs to fully document this oddity. I know that when I go to use the wakeup feature again, I will have forgotten everything that was discussed in this thread.
Also, have any you run into the bug where you need to manually shadow output before going into sleep mode? If you enter sleep mode, output states are lost. You need to read and store then before going to sleep, then restore them upon wakeup. Even then, some outputs will have glitches on them.
-Dan
·
As a demo, rb0-rb2 and rb7 are wakeup inputs, and in this case pullups are enabled. The program wakes up on both the rising edge or the falling edge, which is accomplished by reading rb and using that as a starting point for edge detection each time around the sleep loop.
The events on the pins have to last long enough to be detected by the state machine. That is, it might miss very short pulses. Short pulses would have to be stretched, or some other trick taken. Wkpnd_b is useful for detecting and remembering even short transitions, so long as they are high-->low transitions. Note that the wakeup latency can be much shortened on the SX48/52 (down to 0.15 milliseconds),whereas it is fixed at about 15 milliseconds on the SX20/28.
Dan, all SX outputs briefly become inputs when the chip wakes up from SLEEP. Is that what you are referring to? The direction registers come up as $ff after any reset (powerup, brownout, mclr, wakeup, wdt), and the program has to reinitialize them as outputs if need be. This gap is ~15 milliseconds on the SX20 and SX28, and it can be reduced to as short as 0.15 millisecond on the SX48 and SX52. The data sheet says the output registers come up unchanged after (wakeup, mclr, or wdt) but they are undefined after (powerup or brownout).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Post Edited (Tracy Allen) : 2/13/2006 3:03:50 AM GMT