 |
 |
| View previous topic :: View next topic |
| Author |
Message |
kamyip
Joined: 14 Oct 2003
Posts: 10
|
| interesting and unexplain ext-int problem in P16F876 |
 Posted: Tue Oct 14, 2003 3:47 am |
 |
|
Hi,
I've just discovered a very interesting problem with ext int which left me puzzle. Hopefully someone out there have had similar experience and be able to shed some light on it.
Compiler: PCW 3.007
PIC Target: PIC16F876
Problem:
1)Ext Int enabled
2)At some point of the program, ext int was trigger eventhough there is no external signal to trigger it.
3)How could this be happening?
Sample software:
Ext int was enabled as per:
INTCON &=~(1<<INTF);//make sure flag is reset
ext_int_edge(H_TO_L);
enable_interrupts(INT_EXT);
enable_interrupts(global);
//Interrupt subs are here
#int_ext
Ext_isr(){
restart_wdt();
fInt=TRUE;
}
//main program looks something like this
void main() {
int v_Data; //Rx IR code is store here
//Initialize all the needed memory and output
#include "init100.h"
///////////////////////////////////////////////////////
while(TRUE){
restart_wdt();
s_CheckInt();
if(!fRoom){ //fRoom
Room=TRUE;
s_KeyTag(RoomOn);
s_KeyTag_Write(FALSE);
}
//check for remote control
v_Data = s_GetCode();
if (v_Data != 0xff){
s_CheckNo(v_Data); //check no
s_Time_ms(150);
}
}
}
[/b] |
|
 |
Ttelmah
Guest
|
| Re: interesting and unexplain ext-int problem in P16F876 |
| Posted: Tue Oct 14, 2003 7:44 am |
|
|
| kamyip wrote: | Hi,
I've just discovered a very interesting problem with ext int which left me puzzle. Hopefully someone out there have had similar experience and be able to shed some light on it.
Compiler: PCW 3.007
PIC Target: PIC16F876
Problem:
1)Ext Int enabled
2)At some point of the program, ext int was trigger eventhough there is no external signal to trigger it.
3)How could this be happening?
Sample software:
Ext int was enabled as per:
INTCON &=~(1<<INTF);//make sure flag is reset
ext_int_edge(H_TO_L);
enable_interrupts(INT_EXT);
enable_interrupts(global);
//Interrupt subs are here
#int_ext
Ext_isr(){
restart_wdt();
fInt=TRUE;
}
//main program looks something like this
void main() {
int v_Data; //Rx IR code is store here
//Initialize all the needed memory and output
#include "init100.h"
///////////////////////////////////////////////////////
while(TRUE){
restart_wdt();
s_CheckInt();
if(!fRoom){ //fRoom
Room=TRUE;
s_KeyTag(RoomOn);
s_KeyTag_Write(FALSE);
}
//check for remote control
v_Data = s_GetCode();
if (v_Data != 0xff){
s_CheckNo(v_Data); //check no
s_Time_ms(150);
}
}
}
[/b] |
If you change the edge used on this interrupt, you may result in the internal flag being set. Hence, you should clear the interrupt flag before the global enable, and after setting the edge. It may be this that you are seeing, since it will result in a single call to the handler, as soon as the global interrupt is set (note that having the interrupt disabled when you change the edge, does not prevent the interrupt flag itself being set).
Hence add:
#bit INTF=0xB.1
Then after enabling this interrupt, but before the global enable, add:
INTF=0;
This may solve your problem.
Best Wishes |
|
|
kamyip
Joined: 14 Oct 2003
Posts: 10
|
| Re: interesting and unexplain ext-int problem in P16F876 |
| Posted: Wed Oct 15, 2003 8:06 pm |
|
|
| Ttelmah wrote: | | kamyip wrote: | Hi,
I've just discovered a very interesting problem with ext int which left me puzzle. Hopefully someone out there have had similar experience and be able to shed some light on it.
Compiler: PCW 3.007
PIC Target: PIC16F876
Problem:
1)Ext Int enabled
2)At some point of the program, ext int was trigger eventhough there is no external signal to trigger it.
3)How could this be happening?
Sample software:
Ext int was enabled as per:
INTCON &=~(1<<INTF);//make sure flag is reset
ext_int_edge(H_TO_L);
enable_interrupts(INT_EXT);
enable_interrupts(global);
//Interrupt subs are here
#int_ext
Ext_isr(){
restart_wdt();
fInt=TRUE;
}
//main program looks something like this
void main() {
int v_Data; //Rx IR code is store here
//Initialize all the needed memory and output
#include "init100.h"
///////////////////////////////////////////////////////
while(TRUE){
restart_wdt();
s_CheckInt();
if(!fRoom){ //fRoom
Room=TRUE;
s_KeyTag(RoomOn);
s_KeyTag_Write(FALSE);
}
//check for remote control
v_Data = s_GetCode();
if (v_Data != 0xff){
s_CheckNo(v_Data); //check no
s_Time_ms(150);
}
}
}
[/b] |
If you change the edge used on this interrupt, you may result in the internal flag being set. Hence, you should clear the interrupt flag before the global enable, and after setting the edge. It may be this that you are seeing, since it will result in a single call to the handler, as soon as the global interrupt is set (note that having the interrupt disabled when you change the edge, does not prevent the interrupt flag itself being set).
Hence add:
#bit INTF=0xB.1
Then after enabling this interrupt, but before the global enable, add:
INTF=0;
This may solve your problem.
Best Wishes |
I've gone thru the program again moving the reset ext int flag just before global int enable, the same probel crop-up. My observation as below:
1) Program goes into main() on power
2) initialization was with ext int and global int enable
3) After init it goes into while(TRUE){} super loop which has two major tasks
a. Check for a valid IR signal and send a corresponding command to a I2C device using a polling mechanism
b. Wait for an ext int signal from another i2c device and immediately act by reading from it and set a global flag accordingly
Discussion:
Program wise, I'd not expect any int to happen if threr is no int signal LOW to INT pin of PB0. In this case I have disconnected the outside int source completely and just tied the pin high.
Occasionally, with every valid IR code received and acted upon, SOMEHOW SOMETHING causes the program to goes into int and serviced the int routine. The main problem I've in debugging this problem is it seems to be intermitten which logically speaking made me worried.
Few thing I'm sure was:
1) No WDT reset - as I've turn off the WDT function
2) No other master rese t or POR or BOR was observed.
Have I miss out something?
Pls help |
|
|
Ttelmah
Guest
|
| Re: interesting and unexplain ext-int problem in P16F876 |
| Posted: Thu Oct 16, 2003 8:26 am |
|
|
| Quote: |
I've gone thru the program again moving the reset ext int flag just before global int enable, the same probel crop-up. My observation as below:
1) Program goes into main() on power
2) initialization was with ext int and global int enable
3) After init it goes into while(TRUE){} super loop which has two major tasks
a. Check for a valid IR signal and send a corresponding command to a I2C device using a polling mechanism
b. Wait for an ext int signal from another i2c device and immediately act by reading from it and set a global flag accordingly
Discussion:
Program wise, I'd not expect any int to happen if threr is no int signal LOW to INT pin of PB0. In this case I have disconnected the outside int source completely and just tied the pin high.
Occasionally, with every valid IR code received and acted upon, SOMEHOW SOMETHING causes the program to goes into int and serviced the int routine. The main problem I've in debugging this problem is it seems to be intermitten which logically speaking made me worried.
Few thing I'm sure was:
1) No WDT reset - as I've turn off the WDT function
2) No other master rese t or POR or BOR was observed.
Have I miss out something?
Pls help |
1) Noise.
Could be supply noise, or pick-up on the input pin (depends how low the resistor value is pulling the signal high, and what wiring is attached to the pin). Where is the 5v 'source' for this, relative to the processors 5v connection?. Remember that the interrupt input will pick up tiny signal spikes, that are not easy to detect with a normal scope.
Branching to an unexpected address, is allmost 'classic' for HF supply noise. How are the chips Vdd connections made (having only one connected can cause this sort of behaviour)?. How is the supply rail regulated/decoupled?.
Best Wishes |
|
|
kamyip
Joined: 14 Oct 2003
Posts: 10
|
| Re: interesting and unexplain ext-int problem in P16F876 |
| Posted: Fri Oct 17, 2003 11:36 pm |
|
|
| Ttelmah wrote: | | Quote: |
I've gone thru the program again moving the reset ext int flag just before global int enable, the same probel crop-up. My observation as below:
1) Program goes into main() on power
2) initialization was with ext int and global int enable
3) After init it goes into while(TRUE){} super loop which has two major tasks
a. Check for a valid IR signal and send a corresponding command to a I2C device using a polling mechanism
b. Wait for an ext int signal from another i2c device and immediately act by reading from it and set a global flag accordingly
Discussion:
Program wise, I'd not expect any int to happen if threr is no int signal LOW to INT pin of PB0. In this case I have disconnected the outside int source completely and just tied the pin high.
Occasionally, with every valid IR code received and acted upon, SOMEHOW SOMETHING causes the program to goes into int and serviced the int routine. The main problem I've in debugging this problem is it seems to be intermitten which logically speaking made me worried.
Few thing I'm sure was:
1) No WDT reset - as I've turn off the WDT function
2) No other master rese t or POR or BOR was observed.
Have I miss out something?
Pls help |
1) Noise.
Could be supply noise, or pick-up on the input pin (depends how low the resistor value is pulling the signal high, and what wiring is attached to the pin). Where is the 5v 'source' for this, relative to the processors 5v connection?. Remember that the interrupt input will pick up tiny signal spikes, that are not easy to detect with a normal scope.
Branching to an unexpected address, is allmost 'classic' for HF supply noise. How are the chips Vdd connections made (having only one connected can cause this sort of behaviour)?. How is the supply rail regulated/decoupled?.
Best Wishes |
Hi again,
I'vd got the bug fixed. It is both a timing and flux case. Hopefully for those who are reading this , learn from my mistake and save yourself hours of torture. Let me explain:
1) Everytime a valid IR signal was decoded, a command was sent to SAA1064 I2c chip. The command looks like this START-Add-0x00-DataByte1-DataByte2-STOP
2) An Int will be generated when PCF8574 detected a change in its input and directed the processor to read the new pin status also I2C protocol
The problem starts after repeated command being sent to SAA1064. When i2c Tx buffer is not empty, that particular byte will just be skip. In this case the add byte was skip leaving only START-0x00-...
Now it just so happen that START-0x00 is a master address call to all I2c device which is why PCF8574 unknowing got involve and give me the uncalled for int!!
Solution:
Make sure the I2c tx buffer is empty before the next byte!
Anyway thanks for suggestion. |
|
|
Mark
Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA
|
|
| Posted: Sat Oct 18, 2003 6:42 am |
|
|
Read your orginal post. The information that you gave was misleading. An external int was generated. Also, there is no information about any of the stuff causing your problem! The lesson to be learned here is:
1. Give accurate information. Don't suppose anything.
2. Post a complete enough program that we can figure out the problem. |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
