 |
 |
| View previous topic :: View next topic |
| Author |
Message |
cyclonite
Joined: 10 Sep 2005
Posts: 2
|
| troubles with resetting pic16f876 with current code |
 Posted: Sat Sep 10, 2005 7:31 am |
 |
|
I am using a pic16f876 to generate pwm outpus for 16 leds.
I can send the settings >> % pwm via i2c.
now i have 4 pre programmed mode's 1=leds off
2= leds 100% on 3= ~20% on 4= the half burns at 20% and the rest at 80%
mode 1 and 2 work perfectly but when i select mode 3 the pic seems to reset and goes in the pre defined-start-up mode 1 (leds off)
http://www.diecyde.com/~download/forum/codeproject.zip
maybe someone can help me solve this problem, because i am on the point of throwing things :D |
|
 |
Ttelmah
Guest
|
|
| Posted: Sat Sep 10, 2005 9:35 am |
|
|
Without looking too deeply, try a couple of changes.
First put the I2C interrupt handler in front of the RTCC handler (or use the priority code to give it th higher priority). The I2C, is the 'more important' thing to get handled quickly if data arrives, and this could cause problems.
Second, avoid the risk that the RTCC interrupt occurs between changing bytes in the switch statement. Currently, you are looping flat out, rewriting these bytes all the time, and the interrupt could occur anwhere. You have a synchronise flag to allow the external code to synchronise with the internal code, so use it. Something like:
| Code: |
void test_troep(){
intoccur=1;
while(intoccur);
switch(types_sel){
case 0: //all leds off
onval=0x00;
offval=0x00;
pwmval=16;
break;
case 1: //all leds on
onval=0xff;
offval=0x00;
pwmval=16;
break;
case 2: //blinking
onval=0xff;
offval=0x00;
pwmval=8;
break;
case 3: //even/odd blinking
onval=0xaa;
offval=0x55;
pwmval=1;
break;
case 30: //all leds off
onval=0x00;
offval=0x00;
pwmval=0;
break;
}
}
|
This way the routine will wait at the start of the sub, till an RTCC interrupt occurs, avoiding the risk of having the values 'half changed' when the interrupt happens.
You don't need to clear the SSPIF at the end of the interrupt (the compiler does this for you, unless you put 'noclear' in the interrupt definition).
Also as a general comment, though the compiler should optimise it to 'inline', why not just define read_i2c as:
#define read_i2c() (PIC_SSPBUF)
This ensure the compiler does not end up adding an uneccesary call and return inside the interrupt handler.
I am somewhat 'puzzled' by the initialisation value you have for the SSP module. You are writing '0x81' to the SSPCON2 register. The '8', enables general call enable support, which is only used as a slave device, while the '1' turns on start condition enable, which is only used by a master device... You should rethink the initialisation.
I'd run the start of the code through the MPLAB simulator, and verify that al the peripherals that share pins with the ports being used, are disabled. One of these being left 'on', could cause problems.
I'd also look twice at the decoupling round the chip. Obviously the 'flash' modes would show up an error here more than the static versions.
Best Wishes |
|
|
Guest
|
|
| Posted: Sat Sep 10, 2005 3:25 pm |
|
|
first thank you for your feedback
I first had the ssp int in front of my rtcc int but I changed this because I got the same error.
I think the intoccur solution is something I can try, I'll post the results tommorow.
but my findings were pretty strange, I can transfer all data safely from the master to the slave and back.
then I post it in a little integer and the device seems to reset 
when i transfer a 1 or a 3 in the int the device works properly 
So when I load a 2 in the int types_sel the device seems to reset and loads types_sel with the initial value 0
about the init of the ssp module:
| Ttelmah wrote: | I am somewhat 'puzzled' by the initialisation value you have for the SSP module. You are writing '0x81' to the SSPCON2 register. The '8', enables general call enable support, which is only used as a slave device, while the '1' turns on start condition enable, which is only used by a master device... You should rethink the initialisation.
|
I checked the pdf again and it says for sspcon2
bit 7 general call enable bit which i need
bit 1 start condition enabled / stretch
in slave mode this enables clock streching on both the transmit and receive
thats why 0x81
I loaded several chips with the same code for multiple times but they all give me the same results. |
|
|
Guest
|
|
| Posted: Sat Sep 10, 2005 3:25 pm |
|
|
first thank you for your feedback
I first had the ssp int in front of my rtcc int but I changed this because I got the same error.
I think the intoccur solution is something I can try, I'll post the results tommorow.
but my findings were pretty strange, I can transfer all data safely from the master to the slave and back.
then I post it in a little integer and the device seems to reset
when i transfer a 1 or a 3 in the int the device works properly
So when I load a 2 in the int types_sel the device seems to reset and loads types_sel with the initial value 0
about the init of the ssp module:
| Ttelmah wrote: | I am somewhat 'puzzled' by the initialisation value you have for the SSP module. You are writing '0x81' to the SSPCON2 register. The '8', enables general call enable support, which is only used as a slave device, while the '1' turns on start condition enable, which is only used by a master device... You should rethink the initialisation.
|
I checked the pdf again and it says for sspcon2
bit 7 general call enable bit which i need
bit 1 start condition enabled / stretch
in slave mode this enables clock streching on both the transmit and receive
thats why 0x81
I loaded several chips with the same code for multiple times but they all give me the same results. |
|
|
cyclonite
Joined: 10 Sep 2005
Posts: 2
|
|
| Posted: Sun Sep 11, 2005 4:16 am |
|
|
I have located the problem in the function output_bytes();
| Code: |
void output_bytes(int input1,int input2){
output_a(input1 & 0x2f);
output_bit(pin_c5,bit_test(input1,4)); //bit 4
output_bit(pin_c1,bit_test(input1,6));
output_bit(pin_c2,bit_test(input1,7));
output_b(input2);
}
|
the processor resets when input1 or input2 is 0x00
other value's have no trouble.
edit:
I have tested the code and found that the trouble maker is the output_b function does anyone have any experience with the same problem? executing output_b(0x00); and having the processor resetting? |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Sun Sep 11, 2005 1:29 pm |
|
|
| Quote: | | I have tested the code and found that the trouble maker is the output_b function |
1. Do you have LEDs on Port B ?
2. How many LEDs are you trying to turn on simultaneously when
the PIC resets ?
3. How are the LEDs connected to the port ? i.e., Does the PIC provide
a high level to turn on the LEDs, or does a low level on Port B pins
turn them on ?
4 Do you have a series resistor for each LED ? If so, what is the
value of the resistors ? |
|
|
cyclonite
Joined: 10 Sep 2005
Posts: 2
|
|
| Posted: Sun Sep 11, 2005 4:14 pm |
|
|
1: I have leds on portb
2: if i turn all leds on the proc works fine but when I send an 0x00 to output_b (to turn the leds of) it resets
3: the PIC provides the high level of 5v PWM
4: I believe I use resistors of 300 ohm.
I have the specs of the leds not here right nog, I 'll post them later, but it is calculated.
also the schematic is designed with decoupling condensators . etc...
I should mention output_a() works fine and the portc side also... |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Sun Sep 11, 2005 4:32 pm |
|
|
Try the following simple test program, which toggles Port B between
0x00 and 0xFF. It also writes to the RS-232 port to show the progress.
Does this program cause your PIC to reset or lock-up ?
| Code: | #include <16F876A.H>
#fuses XT, NOWDT, NOPROTECT, BROWNOUT, PUT, NOLVP
#use delay(clock = 4000000)
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7, ERRORS)
//======================================
main(void)
{
int8 i;
i = 0;
while(1)
{
printf("%u\n\r", i);
i++;
output_b(0xFF);
delay_ms(500);
output_b(0x00);
delay_ms(500);
}
} |
|
|
|
Guest
|
|
| Posted: Mon Sep 12, 2005 4:33 am |
|
|
We have changed something in the output routine:
| Code: |
void output_bytes(int input1,int input2){
output_a(input1 & 0x2f); // & 0x2f
output_bit(pin_c5,bit_test(input1,4)); //bit 4
output_bit(pin_c1,bit_test(input1,6));
output_bit(pin_c2,bit_test(input1,7));
output_bit(pin_b0,bit_test(input2,0));
output_bit(pin_b1,bit_test(input2,1));
output_bit(pin_b2,bit_test(input2,2));
output_bit(pin_b3,bit_test(input2,3));
output_bit(pin_b4,bit_test(input2,4));
output_bit(pin_b5,bit_test(input2,5));
output_bit(pin_b6,bit_test(input2,6));
output_bit(pin_b7,bit_test(input2,7));
//output_b(input1|0x55);
}
|
Now everything works like supposed! Does anybody knows why?? |
|
|
Ttelmah
Guest
|
|
| Posted: Mon Sep 12, 2005 5:25 am |
|
|
I'd say 'noise'.
With the non-working code, you are switching 8 lines all low together. depending on the loads actually conncted, and the decoupling round the circuit, this will generate a larger signal 'spike', than switching the lines one at a time. I'd suspect that somwhere in the interconnections here, there is signal coupling taking place leading to a glitch...
Best Wishes |
|
|
Guest
|
|
| Posted: Mon Sep 12, 2005 5:31 am |
|
|
| Ttelmah wrote: | I'd say 'noise'.
With the non-working code, you are switching 8 lines all low together. depending on the loads actually conncted, and the decoupling round the circuit, this will generate a larger signal 'spike', than switching the lines one at a time. I'd suspect that somwhere in the interconnections here, there is signal coupling taking place leading to a glitch...
Best Wishes |
Strange explanation: I should say, when we turn the leds ON this 'spike' should occur, not when we turn them off! Also: when we do the same with port A and a few of port C (to come to 8 leds) this works fine... enough decoupling I should say?
And when we don't use port A, and only try to use port B we come out with same results!
As I mentioned... there are decoupling condensators! |
|
|
Mark
Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA
|
|
| Posted: Mon Sep 12, 2005 6:00 am |
|
|
| Use the simulator in MPLAB. See if that causes a reset. If not, then listen to what others say. |
|
|
|
|
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
