problems using the PIC16c924

[Rafael Moreno]

To: users of pic16c924 and the CCS C compiler. Has anybody run into PIC execution problems while using ISRs from timers and/or SSP module? my problem is that the ISR is serviced but the processor is lost somewhere from main routine. If i remove the ISR routine then the processor runs smoothly and execution of code is normal.
___________________________
This message was ported from CCS's old forum
Original Post ID: 144516659

[PCM programmer]

:=To: users of pic16c924 and the CCS C compiler. Has anybody run into PIC execution problems while using ISRs from timers and/or SSP module? my problem is that the ISR is serviced but the processor is lost somewhere from main routine. If i remove the ISR routine then the processor runs smoothly and execution of code is normal.
--------------------------------------------------------

Post your isr, and also give the version of your compiler.
___________________________
This message was ported from CCS's old forum
Original Post ID: 144516660

[qm]

:=To: users of pic16c924 and the CCS C compiler. Has anybody run into PIC execution problems while using ISRs from timers and/or SSP module? my problem is that the ISR is serviced but the processor is lost somewhere from main routine. If i remove the ISR routine then the processor runs smoothly and execution of code is normal.

I have been trying to deal with the same problem for quite some time. I am using a pic16f872, with compiler version 3.110. Here's a slimmed down version of my code which replicates this problem. The PIC will run (i.e. the red LED on pin c1 will blink) until there is some I2C activity.

Note that the ISR is empty. The problem occurs even with a full-fledged ISR there. It also occurs if there is a default ISR , but it does not occur without any ISR.

#include <16F872.h>
#fuses HS,NOWDT,NOPROTECT,PUT
#use delay(clock=20000000)

// Pin aliases
#define RED_LED PIN_C1 // Red LED output

// Enable manual setting of directions on ports B and C
#use fast_io(b)
#use fast_io(c)
int8 tris_b = 0b11111111;
int8 tris_c = 0b00011000;

// I2C definitions
#define SDA_PIN PIN_C4 // I2C Serial DAta line
#define SCL_PIN PIN_C3 // I2C Serial Clock Line

#define SLAVE_ADDRESS 0xC4

#bit GIE =0x0B.7 // global interrupt enable
#bit PEIE =0x0B.6 // peripheral interrupt enable
#bit SSPIF =0x0C.3 // SSP interrupt flag
#byte SSPBUF =0x13 // SSP buffer
#byte SSPCON =0x14 // SSP control
#bit CKP =0x14.4 // clock polarity select
#bit SSPIE =0x8C.3 // SSP interrupt enable
#bit GCEN =0x91.7 // general call enable
#byte SSPADD =0x93 // SSP address
#byte SSPSTAT =0x94 // SSP statusS
#bit BF =0x94.0 // buffer full
#bit UA =0x94.1 // update address
#bit R_W =0x94.2 // read/!write
#bit S =0x94.3 // start
#bit P =0x94.4 // stop
#bit D_A =0x94.5 // data/!address
#bit CKE =0x94.6 // clock edge select
#bit SMP =0x94.7 // sample bit

void main() {
int trash, redstate = 0;

set_tris_b(tris_b);
set_tris_c(tris_c);

SSPCON = 0;
SSPSTAT = 0;
SSPIF = 0;
trash = SSPBUF; // clear BF

// Configure I2C
SSPADD = SLAVE_ADDRESS; // Configure address
CKE = 0; // Input levels conform to I2C spec
GCEN = 1; // General Call enable (i.e. respond to broadcast address)
SSPCON = 0b00110110; // SSPM[3:0] = 0110: I2C slave mode, 7-bit address
// CKP = 1: Enable clock (i.e. don't hold it low)
// SSPEN = 1: Enable MSSP module (do this last)

SSPIE = 1; // SSP interrupt enable
PEIE = 1; // Peripheral interrupt enable
GIE = 1; // Global interrupt enable

while(1) {
if (redstate) {
redstate= 0;
output_high(RED_LED);
} else {
redstate = 1;
output_low(RED_LED);
}
delay_ms(100);
}
}

#int_ssp
void ssp_handler(void) {
}
___________________________
This message was ported from CCS's old forum
Original Post ID: 144516662

[qm]

<font face="Courier New" size=-1>:=To: users of pic16c924 and the CCS C compiler. Has anybody run into PIC execution problems while using ISRs from timers and/or SSP module? my problem is that the ISR is serviced but the processor is lost somewhere from main routine. If i remove the ISR routine then the processor runs smoothly and execution of code is normal.


My hacked solution to this is to add a bit of assembly at the end of my ISR. It's not pretty, but it seems to work:

#int_ssp
void ssp_handler(void) {

// Normal handler code goes here

#asm
BCF 0x0C,3 // This clears the SSPIF
MOVF 0x27,W // The rest of this is copied from the end of the
// main interrupt routine in the LST file.
MOVWF 0x04
MOVF 0x28,W
MOVWF 0x20
MOVF 0x29,W
MOVWF 0x21
MOVF 0x2A,W
MOVWF 0x22
MOVF 0x2B,W
MOVWF 0x23
MOVF 0x2C,W
MOVWF 0x24
MOVF 0x2D,W
MOVWF 0x0A
SWAPF 0x26,W
MOVWF 0x03
BCF 0x03,5
SWAPF 0x25,W
BTFSC 0x26,1
BSF 0x03,5
RETFIE // Return from interrupt
#endasm
}</font>
___________________________
This message was ported from CCS's old forum
Original Post ID: 144516688