9S08QG inputs won't work in background debug mode only

[irob]

I have a MC9S08QG4 target with one input switch that doesn't work in background debug mode.  I step through the condition and the debugger doesn't see my switch input.

Yet, running normal operation, this same switch on the same target will work, and I verify by lighting an LED.  So odd.

Any thoughts?

[irob]

Well, as Peg noted, I seem to have all the bizarre things happen to me.

I've finally had more time to devote to this again and now my previous bugginess has all but disappeared.  Even the macros are working again.

But then, I have changed a few areas which maybe all together have made all the difference.  For instance:

1. I've been paying more attention lately to RAM and stack allocation.  Though my code has been compiling, I've noticed that very odd, unpredictable behavior can occur when my stack is too small.
2. I've replaced all the bitwise comparisons with logicals.  I had a few double ANDs and ORs elsewhere.  This has saved quite a bit of ROM too!
   

[bigmac]

Hello iRob,

Perchance would the switch be connected to PTA4?

Regards,

Mac

[irob]

No, I have three switches connected to PTB0, 1, 2.  The if() statement I couldn't get to work in the debugger actually checked for all three switches depressed.  I know for a fact that I have no cabling problems as all three of the switches work elsewhere in the code.

To make this work for now, I found that if I shrink that if() statement criteria down to just one of the switches, the debugger then "sees" my switch depress.

One final discovery: if I strip out all of my code except for that triple switch if() statement, and rerun in the debugger, the if() works.  It's almost as if this is a space issue?  Or stack?  I tried growing the stack as high as it would go, but no change.  Very bizarre.

[celsoken]

Dear Irob,

In order to be sure you are working inside specs, are your resistors PU or PD at wich value? I ask U that because sometimes internal PU can manage your inputs to undefined levels and the uC go nuts, with bizarre behaviour.

I hope it helps.

Cheers,

Celso

[irob]

I'm using the internal pullups on all three.  I don't have external pullups on these lines.

[irob]

I just conducted a few tests.  I put some external 10K resistor pullups on each of those three inputs.  I change the code to test individually the three inputs one at a time.  The first time I tested PTB0 and with the pullup it worked.  Without it, it did not.  Seemed promising.

Then (you're not going to believe this), I tried the other two switch inputs on PTB1 and 2 and they did not work.  I went back to PTB0 and it also does not work now.  I don't get it!

Just to check my setup, I tried again stripping out all of the other program code and tested just that simple if function:

Code:

if ((PLUS==CLOSE) & (MINUS==CLOSE) & (MODE==CLOSE)){  TEST = 1;}

This works with merely the internal pullups by itself (no other program code).  The larger my code gets, the debugger can't see those inputs.

[ok2ucx]

Hi,

I just noticed one obvious mistake of your simple code, which is arithmetically ANDing all three conditions instead of logical AND.

You should use && instead of &. Let have a look how differently the code compiles (if ever it is correct) in comparison with the right coding witgh &&

Code:

  391:    if ((SW2 == SW_OFF) & (SW3 == SW_ON) & (SW4 == SW_OFF))  0037 050002   [5]             BRCLR 2,_PTAD,L3C ;abs = 003c  003a 4f       [1]             CLRA    003b 65       [3]             SKIP2 L3E ;abs = 003e  003c          [5]     L3C:      003c a601     [2]             LDA   #1  003e          [5]     L3E:      003e 95       [2]             TSX     003f e701     [3]             STA   1,X  0041 060002   [5]             BRSET 3,_PTAD,L46 ;abs = 0046  0044 5f       [1]             CLRX    0045 65       [3]             SKIP2 L48 ;abs = 0048  0046          [5]     L46:      0046 ae01     [2]             LDX   #1  0048          [5]     L48:      0048 9eef04   [4]             STX   4,SP  004b 95       [2]             TSX     004c e603     [3]             LDA   3,X  004e e401     [3]             AND   1,X  0050 010002   [5]             BRCLR 0,_PTBD,L55 ;abs = 0055  0053 5f       [1]             CLRX    0054 65       [3]             SKIP2 L57 ;abs = 0057  0055          [5]     L55:      0055 ae01     [2]             LDX   #1  0057          [5]     L57:      0057 9eef04   [4]             STX   4,SP  005a 95       [2]             TSX     005b e702     [3]             STA   2,X  005d e603     [3]             LDA   3,X  005f e402     [3]             AND   2,X  0061 2705     [3]             BEQ   L68 ;abs = 0068  392:    {  393:      i = 1;  0063 a601     [2]             LDA   #1  0065 c70000   [4]             STA   i  0068          [5]     L68:      394:    }  395:    396:    if ((SW2 == SW_OFF) && (SW3 == SW_ON) && (SW4 == SW_OFF))  0068 04000b   [5]             BRSET 2,_PTAD,L76 ;abs = 0076  006b 070008   [5]             BRCLR 3,_PTAD,L76 ;abs = 0076  006e 000005   [5]             BRSET 0,_PTBD,L76 ;abs = 0076  397:    {  398:      i = 2;  0071 a602     [2]             LDA   #2  0073 c70000   [4]             STA   i  0076          [5]     L76:

 
Regards, Pavel

[irob]

Another observation -- Though I'm have a heck of a time with the debugger right now, this same code works when running on its own.

I have three different coloed LEDs to set in all the various if statements.  And they are all lighting with their corresponding switch closures.  So it's something about how my code looks to the debugger which isn't working.

[irob]

Pavel, this is an interesting find.  And I'm getting similar compiler results between the two approaches:

Code:

  if ((PLUS==CLOSE) && (MINUS==CLOSE) && (MODE==CLOSE))  {    plus_flag = 1;    minus_flag = 1;    mode_flag = 1;   while ((PLUS==CLOSE) && (MINUS==CLOSE) && (MODE==CLOSE)) // wait for release   {     __RESET_WATCHDOG();     // feed the dog   }  }  if ((PLUS==CLOSE) & (MINUS==CLOSE) & (MODE==CLOSE))  {    plus_flag = 1;    minus_flag = 1;    mode_flag = 1;   while ((PLUS==CLOSE) & (MINUS==CLOSE) & (MODE==CLOSE)) // wait for release   {     __RESET_WATCHDOG();     // feed the dog   }  }  if (PLUS==CLOSE)  {    plus_flag = 1;    minus_flag = 0;    mode_flag = 0;   while (PLUS==CLOSE)  // wait for release   {     __RESET_WATCHDOG();     // feed the dog   }  }  if (MINUS==CLOSE)  {    plus_flag = 0;    minus_flag = 1;    mode_flag = 0;   while (MINUS==CLOSE)   // wait for release   {     __RESET_WATCHDOG();     // feed the dog   }  }  if (MODE==CLOSE)  {    plus_flag = 0;    minus_flag = 0;    mode_flag = 1;   while (MODE==CLOSE)  // wait for release   {     __RESET_WATCHDOG();     // feed the dog   }  }

This code was put into a new project, so this is all that is being compiled.  I get some very bizarre behavior.  With the above, the logical AND if statement does not work.  The incorrect arithmetic AND does evaluate true.  The next two if's with each separate input don't work either.  The Mode button input does work.  I've looked at 0x0002 (the PTB port where my switches are located) and they show as 0x07 when open and low when closed.

Now, if I take out the incorrect arithmetic AND block (the second if statment), then the rest of the if's evaluate true when buttons are pressed!  Like magic.  And all of this is repeatable.  I can comment out that bad block, it all works; uncomment and most everything is broken.

Just the presence of my original loop is causing everything else not to work?  That makes no sense to me at all.  Strange ghosts, these are indeed.

[CompilerGuru]

Could you change the code so it gets compilable on its own?
I mean so that it does not have any unresolved dependencies like PLUS, CLOSE (I guess some macros?) or the plus_flag variable.
Checking the preprocessor output may also help eventually.

Also which CW version are you using? Which options?

Daniel

[bigmac]

Hello iRob,

I do see some inconsistencies in your test code that could possibly account for the ovserved erratic operation.  Let's examine the first section -

if ((PLUS==CLOSE) && (MINUS==CLOSE) && (MODE==CLOSE)) {
   plus_flag = 1;
   minus_flag = 1;
   mode_flag = 1;
   while ((PLUS==CLOSE) && (MINUS==CLOSE) && (MODE==CLOSE)) { // wait for release
      __RESET_WATCHDOG();
   }
}

Firstly, I am assuming that each of your three tests appropriately generates a logical true result when the associated switch is closed, but otherwise a false condition.  This is not evident from the posted code.  This would then imply that you require the closure of all three  switches for the following code to execute, but the release of only one of the switches to exit from the wait loop.  I might have expected that you would require all three switches to be released before exiting the loop, and would need the following modification.

   /* Wait for release of all switches */

   while ((PLUS==CLOSE) || (MINUS==CLOSE) || (MODE==CLOSE))
      __RESET_WATCHDOG();

Incidently, if you were to do this, the next section of code could rarely execute since it also seems to require that all switches be closed, and it immediately follows a state where all switches are released.

However, as the code stands, if the last of the three switches to be activated should bounce, the first wait loop will exit, the next section of code will probably be skipped because the bounce period will usually exceed the few cycles for the next test, and the tests for individual switches would then occur.  One of the individual switches would register, but because of its associated wait loop, whether or not any other of the switches register a closure during the current passage of the code would depend on the switch release sequence.

With the existing code it remains doubtful that the second section of code would ever execute.  To achieve multiple tests for the same switch state, I might suggest the following modified test code should achieve more predictable results.

if ((PLUS==CLOSE) && (MINUS==CLOSE) && (MODE==CLOSE)) {
   plus_flag = 1;
   minus_flag = 1;
   mode_flag = 1;
   active_flag = 1;

}
if ((PLUS==CLOSE) & (MINUS==CLOSE) & (MODE==CLOSE)) {
   plus_flag = 1;
   minus_flag = 1;
   mode_flag = 1;
   active_flag = 1;

}
if (PLUS==CLOSE) {
   plus_flag = 1;
   minus_flag = 0;
   mode_flag = 0;
   active_flag = 1;

}
if (MINUS==CLOSE) {
   plus_flag = 0;
   minus_flag = 1;
   mode_flag = 0;
   active_flag = 1;

}
if (MODE==CLOSE) {
   plus_flag = 0;
   minus_flag = 0;
   mode_flag = 1;

   active_flag = 1;

}
if (active_flag) {

   /* Implement de-bounce delay here */

}

/* Wait for release of all switches */

while ((PLUS==CLOSE)||(MINUS==CLOSE)||(MODE==CLOSE))
     __RESET_WATCHDOG();

if (active_flag) {

   /* Implement de-bounce delay here */

   active_flag = 0;

}

Regards,

Mac

Message Edited by bigmac on 2007-08-23 10:43 AM

[irob]

Hey Mac, thanks for the long thoughtful post.  I appreciate it, as always!

You make some good observations.  Firstly, yes I intended the first if block to trap on all three buttons pressed.  So your suggestion for the negative condition in the while loop is a good one.

However, regarding the debounce, the code I posted is a simplified version of my "real" code which does debounce the switches.  As soon as I discovered that the debugger may not be reading switch input correctly, I devoted my time to developing test code rather than actual debounced production code.

The very fact that, for instance, the Freescale debugger is not evaluating the two triple-condition if statements in your revised example code worries me far more than anyting else at the moment.  I copied your code verbatim into my project and ran the debugger.  Stepping through the first two if's, the two conditions are never taken as true.  And I can watch register 0x0002 (the PTB) and see its value start at 0xA7 (PTB0-2 all pulled high) before pressing switches, and then change to 0xA0 when I press all three.

Then I step into those if statements, yet the debugger doesn't enter the true condition. Instead, they are skipped over.  Now the individual switch if statements do evaluate true when their respective switches are pressed.  Very, very odd indeed.

[bigmac]

Hello iRob,

You have not yet clarified the content of your macros, to confirm whether they correctly relate the operation of the switches to the logic you have used.  The macros would need to expand to the following, or something logically equivalent, after pre-processing -

if ((PTBD_PTBD0 == 0) && (PTBD_PTBD1 == 0) && (PTBD_PTBD2 == 0)) {

As an alternative test, you could try -

if ((PTBD & 0x07) == 0) {

Regards,

Mac

[irob]

---

bigmac wrote:

You have not yet clarified the content of your macros, to confirm whether they correctly relate the operation of the switches to the logic you have used.  The macros would need to expand to the following, or something logically equivalent, after pre-processing -

if ((PTBD_PTBD0 == 0) && (PTBD_PTBD1 == 0) && (PTBD_PTBD2 == 0)) {

---

Sorry for the delay in responding.  Got swamped last week.  Mac, you and Daniel are indeed correct.  If I replace all the macros with the actual port bits, then the debugger works.  Granted, it seems I have to press the switches about 2 steps before the actual condition arrives, but otherwise it works.

Very curious.  Why would this be?

[J2MEJediMaster]

Might I suggest as a SWAG is that there's a lot of logical operations going on before the comparison test? I wonder if reducing the number of operations, while retaining the logic of the code would help, like so:

desired_switch_combo = PLUS | MINUS | MODE; // Assumes you're polling uniquely positioned bits

if (desired_switch_combo == ALL_SWITCHES_CLOSED_MASK) {

 // then do your stuff..

} // end if

Message Edited by J2MEJediMaster on 2007-08-24 02:03 PM

[celsoken]

Just in case, if you are going analog, pullups are disabled by the alternate function, so you'll need external pullups.

Cheers,

Celso

[irob]

---

celsoken wrote:
Just in case, if you are going analog, pullups are disabled by the alternate function, so you'll need external pullups.

---

Nope, no analog in my code.

[bigmac]

Hello iRob,

With mechanical switches, I am always suspicious of the effects of key bounce causing unpredictable results.  For your real code, if you happen to be toggling a flag for each closure detected, you would need to take de-bounce precautions.  This would be particularly so if you happened to be using KBI interrupts, which I assume you are not.

A simple method for debounce would be, on detection of a closure of one or more of the three switches, to cause a delay of say 50 to 100 ms before re-sampling the state of the switches.

Regards,

Mac

[irob]

I actually do have other routines which debounce those mechanical switches quite nicely.  And it's in the order of milliseconds.  But what I don't understand here is that this simple test routine isn't working in the confined environment of the debugger.

I'm simply stepping through that sample code, so there's not much chance of bouncing switch.  The switch is long closed by the time I step through the if statement.  The if statement will evaluate positively provided my total source code size is very small.  As soon as I put back in the full compiled source code, this switch input won't work in the debugger.

[peg]

Hi Rob,

What do you do to get all these strange problems?

What I would do is measure the input pins voltage with the switch open and closed. If your getting very close to the rails then adding more pullups won't help. If your not, get a better switch.

Temporarily put a 100k resistor across the switch and re-measure the input pin voltage. Now you can calculte the effective internal pullup to be sure it is working/OK.

Have you taken a look at the code produced? I doubt there is an error here but it may help shed some light. Have you tried to code it a different way like ANDing with 7?