:grin: I learned something today!

Woody · Joined: 11 Sep 2003 Posts: 83 Location: Warmenhuizen - NL

Hi,

This is probably something that a lot of people in this forum will say 'Oh well, what's new?' about. But it kept me off the street for half a day, so I'll tell you anyway. Maybe it will help someone else.

I have an application using a 12F675 that counts pulses from an index wheel, powered by a motor switched by the PIC. This wheel turns X times (programmable). The wheelsensor generates an interrupt-on-change. In the interrupt routine a counter (pulse_counter) gets decremented. Pulse_counter is a long, for I need it to be able to contain around 500. In the main loop I set pulse_counter once, start the motor and wait for pulse_counter to reach 0 before I switch the motor off again. I do that by testing: if (pulse_counter == 0x0000)
This works flawless in the initial stages of the project. Then I start to use larger numbers, more in the range of those used in the actual app. And suddenly, every now and then the motor stops way before the correct number of turns has been done.
I try to find some logic in the occurence of the bug, but fail. I then connect a serial rs232 display to my one and only leftover PIC pin to be able to look at the actual value of pulse_counter. I see that when my bug occurs, pulse_counter reads 0x00ff. That starts me thinking, how can the test in the main loop decide that 0x00ff is 0?

Here's how:
When you test a long, the compiler generates code that tests the two bytes of this long separately (obviously). First it loads the LSB, and tests it for 0. If 0, then it tests the MSB. If that is 0 also, the long is 0.
Enter the interrupt. Assume you get an interrupt during this test, between testing the LSB and the MSB. Also, assume the value of your long to be 0x0100. The LSB test sees 0x00, and jumps to test the MSB. Then the interrupt occurs. In the interrupt routine the long gets decremented to 0x00ff. Back to the code where the interrupt occured. The MSB is loaded and tested. This reads also 0 now. So the long reads as 0 now. And my motor gets shut off.....

As I said, I expect that lots of people on this forum find this so logical as not to mention it, but I did not realise this myself and it made me very happy to finally find the source of this intermittent error. I still wonder if CCS could solve this by generating the test the other way around (first the MSB and then the LSB) but that would probably lead to other problems.

Woody.

Mark · Joined: 07 Sep 2003 Posts: 2838 Location: Atlanta, GA

You might not believe this but I had the exact same problem and didn't discover it until about 12:00am this morning!

Testicky · Posted: Sat Dec 06, 2003 9:50 am

Why don't you make a copy of your registers and test the copied registers for 0, this way, their value won't change.
_________________
Testicky

Mark · Joined: 07 Sep 2003 Posts: 2838 Location: Atlanta, GA

Er...Because the program would lock up. The code is waiting for the value to hit 0. It must change!

Woody · Joined: 11 Sep 2003 Posts: 83 Location: Warmenhuizen - NL

Hi,

I solved this by testing in the interrupt routine as well. I then signal the result of this test via one bit in a flag byte that I later test in the main loop. I use that often in my code. Works great.

Woody

KerryW · Guest

I fall for it regularly. When I figure it out, I always say "Oh, yeah, that one again." Embarassed

Disable the interrupts before making the compare, then re-enable them.

Dirk · Guest

Using interrupts can be tricky!
When you change multibyte variables both in interrupt and in main code, you need to disable interrupts.
A better solution is to avoid chaging multbyte varables in two interrupts levels altogether, and to pass counts through a single byte variable.
If the multibyte variable gets changed only during interrupt time, you could test it there and set a flag for the main code when it hits 0.

Dirk

Neutone · Joined: 08 Sep 2003 Posts: 839 Location: Houston

Mark · Joined: 07 Sep 2003 Posts: 2838 Location: Atlanta, GA

I have no problem figuring a way AROUND the problem! I am saying that the compiler manufacturers can change the way they do the test so we don't have to do a "work around".

Ttelmah · Guest

Mark · Joined: 07 Sep 2003 Posts: 2838 Location: Atlanta, GA

I know the chip very well and understand the problem thoroughly! There would be no time penality if the compiler were to switch the order of the reads. Now the code I posted was from the C18 compiler. CCS might not do it the same way. I am not sure. The problem is that the low byte is checked first. If the value were say 0x100 then the low byte would be 0. Now the int occurs and the new value is 0x00FF. Now the high byte is checked and found to be 0 and Houston we have a problem. Now lets reverse the order. The value is 0x100. The high byte is non zero so we continue to wait. Now the value is 0x00FF. The high byte is 0 so check the low byte. It won't be 0 until the value is 0! No penality and works for a zero/non-zero test which is quite common. As for the suggestion of adding the nops, I don't remember why that would do any good Embarassed

Maybe I had a reason or maybe I just stayed up too late! But what I was trying to say was that this special code would only be added if the variable were declared as volatile meaning that it can change from some outside source.

Ttelmah · Guest

Mark · Joined: 07 Sep 2003 Posts: 2838 Location: Atlanta, GA

Note that I said

Ttelmah · Guest

Mark · Joined: 07 Sep 2003 Posts: 2838 Location: Atlanta, GA

I only suggested the test for zero/ nonzero changed. I never said a damn thing about CCS enabling/disabling interrupts! All the code I posted was from the C18 compiler not CCS.