[2]
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.

Hi.

I did not go through your code but to ma 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.

[Quoting: "Digital1010"]
[2]
roblem: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 [/2]

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.

Thanks Guenther, I have cleared it several different ways and it is clearing.

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............

[Quoting: "Digital1010"]
Thanks Guenther, I have cleared it several different ways and it is clearing.

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!

Yes, I was able to go into the sleep mode but i have a few external devices that are still drawing around the 3ma(fully acceptable).  Unfortunately I was hoping to be able to use the WKPND bits with my mix of edges to determine what woke me up and now it's seems that I can't rely on the WKPND (with mixed edges).  So I will have to run continous in a low current mode to know which lines are requesting service.

[Quoting: "Digital1010"]
Yes, I was able to go into the sleep mode but i have a few external devices that are still drawing around the 3ma(fully acceptable). Unfortunately I was hoping to be able to use the WKPND bits with my mix of edges to determine what woke me up and now it's seems that I can't rely on the WKPND (with mixed edges). So I will have to run continous in a low current mode to know which lines are requesting service.

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

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.

Thanks for your info.  It is a nice micro but I thought I was going crazy and was missing the obvious, but apparently not...

Are you using the internal pullups on your H2L inputs?  If so, the WKPND_B won't reflect the correct source of the interrupts on all the pins configured with the internal pull ups.  The pull up resistors must be external. It's not explicitly mentioned but all the info in http://www.parallax.com/dl/docs/prod/sx/SxUsersManualV31.pdf in section 4.4 is correct.  The WKPND_B is unchanged when waking up from sleep.  Also realize that it takes approx. 18 milliseconds to wake up from sleep, so if you're planning on capturing data on a wake up you'll have to accomodate for this , or stay awake.

Thanks for the reply
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.

The bad news is you're right.  All the L2H lines configured for rising edge wake up will show toggled in the WK_PND_B after waking up when only one of the lines is actually toggled.  Interesting.  I have no explaination or work around, and I don't recall this ever being mentioned in the docs. or the now defunct user group in yahoo.....  
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...... :turn:

I verified your observation today, using an SX48 instead of an SX28.   There was a chance the they might be different.  
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.

To which level have you tied the input pins that do _not_ cause a wakeup. Are they pulled low or high by external resistors, or are they floating?

In my setup on an SX48, rb0 to rb3 were configured as inputs and configured for wakeup on edges.  The other port b pins rb4 to rb7 were configured as outputs.   rb0 to rb3 had pushbutton switches with external 10k pullups with 0.01uf for debounce, so action would take place on either the push or the release, depending on the wked_b setting.    Internal pullups were not enabled.   Port ra.2 was used to transmit serial data to the terminal, to observe states.  Other ports ra - re were in some kind of inactive condition, either outputs or inputs with pullups, no signals present.

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.

If you are asking about RB.7 which is the only wakeup line that I don't use, it is floating although I do not enable it as a wakeup in my software.  It probably wouldn't hurt to test RB.7 pulled low even though it's not used.  Stranger things have happened!!!!

I've attached my test program, which sends its ascii debug data out at ra.2.   It is configured to look at rb0, rb1, rb2 and rb3, and to wake up on either edge, rising or falling.   It detects both edges by stuffing the current value of rb into the WKED edge register just before sleep.

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.

Thanks Tracy.  I downloaded the file and will play around with it.  I'll have to look a little closer at the dynamic of the signals that are coming in.  Some keep their logic state but others switch.  Let me experiment with your idea.  I already have some RC on each pin to minimize noise.  I finialized my current code for simple signal indicating whether it was a power up or a wakeup with the hopes that I can later reflash with full wakeup information.  My 1st batch of 350 are coming in next week and I'm under the gun..

Just hit your web site, Very nice!!

A quick look at your code shows that you are looping back to Main after the sleep. The first thing you do in Main is to change the values of the ports, THEN read your pending triggers.  
Could this be causing your problems.  Save your list of pending triggers before looping to Main, or loop to the code after the port initializations.

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.

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.

[2]
I'm really glad that some other people are looking into this bug. I was pulling my hair out last summer, and no one believed me!

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.

To be sure it would work, I modified the demo program to detect transisitons using a state machine dependent on current state, past state and operators, XOR, AND.  That replaces the problematic wkpnd_b register to indicate which input caused the event.    The program displays the contents of rb, wkpnd_b, and the state variables for all transistions, 0->1 transitions, and 1->0 transitions.  WKEN_B is enabled to wake up on change, even though the contents of wkpnd_b are not useful.

Andrew, I tried your suggestions.   Moving the capture of wkpnd_b up before the port initializations did not make a difference.  The wakeup on output pin rb4 was an artifact of trying out too many alternatives.   As it stands now, it is using rb0-rb2 and rb7 as wakeup inputs.   On rb pins initialized as outputs, wkpnd_b returns a zero for outputs iniitialized high, and a one for outputs initialized low.   I did turn on the pullups in this version, but that did not make a difference.   In my setup, there are external pullups and RC debounce.  This should also work with external pulldowns (with internal pullups off).

I see you're right about the interrupt, that it could clobber the serial code.   Interrupts are not enabled in this program, but that would have to be taken care of if they were.  If the program needs to test for transitions while the program is awake, it could run the state machine code in an ISR, or it could run that same code frequently enough in the main loop.  
In a program that stays awake, the wkpnd_b register works okay to detect transitions.  It is problematic only after wakeup from SLEEP.

Dan, I think the SX series have the same glitch as the PIC16C5x series, that all the outputs briefly become inputs when the chip wakes up from SLEEP.   This gap is 18 milliseconds on the SX20 and SX28, and it can be reduced to as short as 0.15 millisecond on the SX48 and SX52.  I'm puzzled by the issue of having to manually restore the outputs.