Forums

Strange behavior of RA4 and RA5 on PIC18F242

Started by Paul E. Schoen February 18, 2007
Hello,

I am new to this NG, but my question seemed more appropriate here than on 
SED.

I'm using a PIC18F242 for an SCR controller, and programming it in assembly 
with MPLAB 7.30. I am using RA4 as an Output On indicator, driving an LED 
and an optoisolator through a series resistor to +5VDC. I use RA5 to drive 
a status LED, low for green and high for red.

Everything worked fine when I had the target board connected to a prototype 
test setup, but when it was installed in a piece of equipment, the Output 
On indicator would latch on sometimes, but would then sometimes work OK 
when the output was turned on and off, so it was not a latch-up of the 
device. RA4 was being driven low (or not driven high) in software. I found 
a few places in my code that could possibly be a loop where the state of 
RA4 might not be set high, but I cleaned it up so there was no longer any 
possibility, and yet the light still latched on.

I spent hours trying to find the problem, and sometimes I could get it to 
latch up on my test board, but it was always worse in the actual unit where 
it was to be installed. I tried removing the 480 VAC supply to the SCRs, 
and also powered the board from external 120 VAC power, but the problem 
persisted. I also added electrical and software filtering to the initiate 
input line, to no avail.

Finally, I decided to implement a debug version of code that used the RA5 
indicator as a gauge for ISR overhead, setting it at the interrupt and 
resetting at exit. I could see that the overhead was OK, on the bench. I 
put it in the unit, and also saw no excessive overhead. But the crazy thing 
is that now the Output On indicator worked perfectly!

So, I just set a flag in a file variable in main line code where I wanted 
to set or reset the Status LED, and added a check in the ISR to actually 
drive the RA5 line. The Output On indicator was still driven as it had been 
in the main code loop.

It works now, but I don't know why. I did not see anything special about 
RA4, except that it is open drain and can be connected to a timer. RA5 
seems to be quite ordinary. I am using RA3 as an analog input. I configure 
PORTA:

 movlw     B'11001011'   ;RA<2,4-5> output
 movwf     TRISA         ;W=>TRISA

Any ideas will be most appreciated. I may make a service ticket to 
Microchip unless anyone can point out a cause for this. I may upgrade to a 
PIC18F2420, which is similar and recommended for new designs. Maybe there 
is a flaw in the 242?

Thanks,

Paul E. Schoen
www.pstech-inc.com 


In article <45d92017$0$6831$ecde5a14@news.coretel.net>, pstech@smart.net 
says...
> Hello, > > I am new to this NG, but my question seemed more appropriate here than on > SED. > > I'm using a PIC18F242 for an SCR controller, and programming it in assembly > with MPLAB 7.30. I am using RA4 as an Output On indicator, driving an LED > and an optoisolator through a series resistor to +5VDC. I use RA5 to drive > a status LED, low for green and high for red. > > Everything worked fine when I had the target board connected to a prototype > test setup, but when it was installed in a piece of equipment, the Output > On indicator would latch on sometimes, but would then sometimes work OK > when the output was turned on and off, so it was not a latch-up of the > device. RA4 was being driven low (or not driven high) in software. I found > a few places in my code that could possibly be a loop where the state of > RA4 might not be set high, but I cleaned it up so there was no longer any > possibility, and yet the light still latched on. > > I spent hours trying to find the problem, and sometimes I could get it to > latch up on my test board, but it was always worse in the actual unit where > it was to be installed. I tried removing the 480 VAC supply to the SCRs, > and also powered the board from external 120 VAC power, but the problem > persisted. I also added electrical and software filtering to the initiate > input line, to no avail. > > Finally, I decided to implement a debug version of code that used the RA5 > indicator as a gauge for ISR overhead, setting it at the interrupt and > resetting at exit. I could see that the overhead was OK, on the bench. I > put it in the unit, and also saw no excessive overhead. But the crazy thing > is that now the Output On indicator worked perfectly! > > So, I just set a flag in a file variable in main line code where I wanted > to set or reset the Status LED, and added a check in the ISR to actually > drive the RA5 line. The Output On indicator was still driven as it had been > in the main code loop. > > It works now, but I don't know why. I did not see anything special about > RA4, except that it is open drain and can be connected to a timer. RA5 > seems to be quite ordinary. I am using RA3 as an analog input. I configure > PORTA: > > movlw B'11001011' ;RA<2,4-5> output > movwf TRISA ;W=>TRISA > > Any ideas will be most appreciated. I may make a service ticket to > Microchip unless anyone can point out a cause for this. I may upgrade to a > PIC18F2420, which is similar and recommended for new designs. Maybe there > is a flaw in the 242? > > Thanks, > > Paul E. Schoen > www.pstech-inc.com >
How are you writing the port? Many a designer got bit by the read- modify-write bug (is it really a bug?) of the PIC. The 18 series has an output latch that can be written to instead of directly reading the port to flip a bit. Jim
"James Beck" <jim@reallykillersystems.com> wrote in message 
news:MPG.2043820937adc58a989eb6@newsgroups.bellsouth.net...
> In article <45d92017$0$6831$ecde5a14@news.coretel.net>, pstech@smart.net > says... >> Hello, >> >> I am new to this NG, but my question seemed more appropriate here than >> on >> SED. >> >> I'm using a PIC18F242 for an SCR controller, and programming it in >> assembly >> with MPLAB 7.30. I am using RA4 as an Output On indicator, driving an >> LED >> and an optoisolator through a series resistor to +5VDC. I use RA5 to >> drive >> a status LED, low for green and high for red. >> >> Everything worked fine when I had the target board connected to a >> prototype >> test setup, but when it was installed in a piece of equipment, the >> Output >> On indicator would latch on sometimes, but would then sometimes work OK >> when the output was turned on and off, so it was not a latch-up of the >> device. RA4 was being driven low (or not driven high) in software. I >> found >> a few places in my code that could possibly be a loop where the state of >> RA4 might not be set high, but I cleaned it up so there was no longer >> any >> possibility, and yet the light still latched on. >> >> I spent hours trying to find the problem, and sometimes I could get it >> to >> latch up on my test board, but it was always worse in the actual unit >> where >> it was to be installed. I tried removing the 480 VAC supply to the SCRs, >> and also powered the board from external 120 VAC power, but the problem >> persisted. I also added electrical and software filtering to the >> initiate >> input line, to no avail. >> >> Finally, I decided to implement a debug version of code that used the >> RA5 >> indicator as a gauge for ISR overhead, setting it at the interrupt and >> resetting at exit. I could see that the overhead was OK, on the bench. I >> put it in the unit, and also saw no excessive overhead. But the crazy >> thing >> is that now the Output On indicator worked perfectly! >> >> So, I just set a flag in a file variable in main line code where I >> wanted >> to set or reset the Status LED, and added a check in the ISR to actually >> drive the RA5 line. The Output On indicator was still driven as it had >> been >> in the main code loop. >> >> It works now, but I don't know why. I did not see anything special about >> RA4, except that it is open drain and can be connected to a timer. RA5 >> seems to be quite ordinary. I am using RA3 as an analog input. I >> configure >> PORTA: >> >> movlw B'11001011' ;RA<2,4-5> output >> movwf TRISA ;W=>TRISA >> >> Any ideas will be most appreciated. I may make a service ticket to >> Microchip unless anyone can point out a cause for this. I may upgrade to >> a >> PIC18F2420, which is similar and recommended for new designs. Maybe >> there >> is a flaw in the 242? >> >> Thanks, >> >> Paul E. Schoen >> www.pstech-inc.com >> > > How are you writing the port? Many a designer got bit by the read- > modify-write bug (is it really a bug?) of the PIC. The 18 series has an > output latch that can be written to instead of directly reading the port > to flip a bit. > > Jim
Yes, I think that is LATA, and I am not using that. I use CLRF PORTA in my initialization, and then write b'11111111' to PORTA. In the ISR (which is used for a 7200/sec timer and also 60 Hz ZC detector) btfss a_data,STATLED bra HIsetGreen HIsetRed: bsf PORTA, STATLED ;Set RED bra HIsetX HIsetGreen: bcf PORTA, STATLED ;Set Green HIsetX: In the main code loop: StartLoop: ;Jump here for error checking bsf a_data,STATLED ;Set HIGH to turn RED LED On ... bcf SCRstat, SCRERR ;Clear error if both flags set (no voltage on gates) bcf a_data,STATLED ;Set LOW to turn GRN LED On (RA5) Initiate: bcf PORTA, OUTON ;Light LED and turn on relay ... return Stop: ... bcf SCRmode, InitOn ;Make sure this is cleared bsf PORTA, OUTON ;Turn off LED and relay return I am using a routine called ChkInit which reads the status of the INIT line on PORTB (25 times with 220 uSec delay per loop for debounce/filtering), and sets or resets the InitOn bit in a file register SCRmode: call ChkInit ;Check status, set/reset SCRmode:InitOn btfss SCRmode, InitOn goto StartLoop ;Loop back to stop and check if not ON goto Loop ;Continue loop if ON In an earlier version of code, I was reading the OUTON bit on PORTA for some processing, but now I read the associated file variable. One other thing, probably not important: I am using AN0 for the A/D input, not AN3 as previously stated. Thanks, Paul
In article <45d9dc84$0$6841$ecde5a14@news.coretel.net>, pstech@smart.net 
says...
> > "James Beck" <jim@reallykillersystems.com> wrote in message > news:MPG.2043820937adc58a989eb6@newsgroups.bellsouth.net... > > In article <45d92017$0$6831$ecde5a14@news.coretel.net>, pstech@smart.net > > says... > >> Hello, > >> > >> I am new to this NG, but my question seemed more appropriate here than > >> on > >> SED. > >> > >> I'm using a PIC18F242 for an SCR controller, and programming it in > >> assembly > >> with MPLAB 7.30. I am using RA4 as an Output On indicator, driving an > >> LED > >> and an optoisolator through a series resistor to +5VDC. I use RA5 to > >> drive > >> a status LED, low for green and high for red. > >> > >> Everything worked fine when I had the target board connected to a > >> prototype > >> test setup, but when it was installed in a piece of equipment, the > >> Output > >> On indicator would latch on sometimes, but would then sometimes work OK > >> when the output was turned on and off, so it was not a latch-up of the > >> device. RA4 was being driven low (or not driven high) in software. I > >> found > >> a few places in my code that could possibly be a loop where the state of > >> RA4 might not be set high, but I cleaned it up so there was no longer > >> any > >> possibility, and yet the light still latched on. > >> > >> I spent hours trying to find the problem, and sometimes I could get it > >> to > >> latch up on my test board, but it was always worse in the actual unit > >> where > >> it was to be installed. I tried removing the 480 VAC supply to the SCRs, > >> and also powered the board from external 120 VAC power, but the problem > >> persisted. I also added electrical and software filtering to the > >> initiate > >> input line, to no avail. > >> > >> Finally, I decided to implement a debug version of code that used the > >> RA5 > >> indicator as a gauge for ISR overhead, setting it at the interrupt and > >> resetting at exit. I could see that the overhead was OK, on the bench. I > >> put it in the unit, and also saw no excessive overhead. But the crazy > >> thing > >> is that now the Output On indicator worked perfectly! > >> > >> So, I just set a flag in a file variable in main line code where I > >> wanted > >> to set or reset the Status LED, and added a check in the ISR to actually > >> drive the RA5 line. The Output On indicator was still driven as it had > >> been > >> in the main code loop. > >> > >> It works now, but I don't know why. I did not see anything special about > >> RA4, except that it is open drain and can be connected to a timer. RA5 > >> seems to be quite ordinary. I am using RA3 as an analog input. I > >> configure > >> PORTA: > >> > >> movlw B'11001011' ;RA<2,4-5> output > >> movwf TRISA ;W=>TRISA > >> > >> Any ideas will be most appreciated. I may make a service ticket to > >> Microchip unless anyone can point out a cause for this. I may upgrade to > >> a > >> PIC18F2420, which is similar and recommended for new designs. Maybe > >> there > >> is a flaw in the 242? > >> > >> Thanks, > >> > >> Paul E. Schoen > >> www.pstech-inc.com > >> > > > > How are you writing the port? Many a designer got bit by the read- > > modify-write bug (is it really a bug?) of the PIC. The 18 series has an > > output latch that can be written to instead of directly reading the port > > to flip a bit. > > > > Jim > > Yes, I think that is LATA, and I am not using that. I use CLRF PORTA in my > initialization, and then write b'11111111' to PORTA. > > In the ISR (which is used for a 7200/sec timer and also 60 Hz ZC detector) > > btfss a_data,STATLED > bra HIsetGreen > HIsetRed: > bsf PORTA, STATLED ;Set RED > bra HIsetX > HIsetGreen: > bcf PORTA, STATLED ;Set Green > HIsetX: > > In the main code loop: > > StartLoop: ;Jump here for error checking > bsf a_data,STATLED ;Set HIGH to turn RED LED On > ... > > bcf SCRstat, SCRERR ;Clear error if both flags set (no voltage on gates) > bcf a_data,STATLED ;Set LOW to turn GRN LED On (RA5) > > > Initiate: > bcf PORTA, OUTON ;Light LED and turn on relay > ... > return > > Stop: > ... > bcf SCRmode, InitOn ;Make sure this is cleared > bsf PORTA, OUTON ;Turn off LED and relay > return > > I am using a routine called ChkInit which reads the status of the INIT line > on PORTB (25 times with 220 uSec delay per loop for debounce/filtering), > and sets or resets the InitOn bit in a file register SCRmode: > > call ChkInit ;Check status, set/reset SCRmode:InitOn > btfss SCRmode, InitOn > goto StartLoop ;Loop back to stop and check if not ON > > goto Loop ;Continue loop if ON > > In an earlier version of code, I was reading the OUTON bit on PORTA for > some processing, but now I read the associated file variable. > > One other thing, probably not important: I am using AN0 for the A/D input, > not AN3 as previously stated. >
I guess I'm not getting my head around EXACTLY what you are doing. Just keep in mind that bit set and bit clear are RMW instructions and you should really be using the latch registers or keep a shadow copy of the output data, but why if the output latches do the same thing and you don't have the problem of a pin that is a loaded output reading as a 0 when it is really driven high (should be treated as a 1). Also, RA4 is an open drain output, so it is not driven high by the IC. It may be pulled up by the load, but maybe not well enough to read as a 1. Also, make sure that any writes to ports you are doing in the main loop can not be interrupted by an ISR that may be modifying the same port. Jim
"James Beck" <jim@reallykillersystems.com> wrote in message 
news:MPG.2043d4c48858c892989eba@newsgroups.bellsouth.net...
[snip]

> > I guess I'm not getting my head around EXACTLY what you are doing. > Just keep in mind that bit set and bit clear are RMW instructions and > you should really be using the latch registers or keep a shadow copy of > the output data, but why if the output latches do the same thing and you > don't have the problem of a pin that is a loaded output reading as a 0 > when it is really driven high (should be treated as a 1). Also, RA4 is > an open drain output, so it is not driven high by the IC. It may be > pulled up by the load, but maybe not well enough to read as a 1. Also, > make sure that any writes to ports you are doing in the main loop can > not be interrupted by an ISR that may be modifying the same port. > > Jim >
You were absolutely correct in your first observation that I have been bitten by the RMW "bug". Now that I have looked carefully at what is involved when setting or resetting an individual port bit, it becomes very clear. I changed all my BSF and BCF PORTx instructions to LATx, and all is well. I kept the btfsc and btfss PORTx instructions as they were because that is exactly what I want. I think I had a similar problem some time ago, and I had "fixed" it by maintaining an image of the port data (as in a_data in my code). I don't know exactly why the code acted as it did, differently in the test setup and the actual application, but definitely there is a potential problem reading an open drain pin connected to non-linear loads like LEDs. The datasheet is very vague about this problem. It shows a CLRF LATA as just an alternate to CLRF PORTA, which it is, but the BSF and BCF instructions are where problems are likely to occur. There are several references to this problem that I dug up on the Microchip website, so you would think they would add a little update on their data sheets to warn about this. I switch back and forth among various projects, including PCB design and Delphi programming, so it is easy to forget some things like this when I've been involved in other things for a while. I appreciate your response. Thanks, Paul
In article <45da8aed$0$6821$ecde5a14@news.coretel.net>, pstech@smart.net 
says...
> > "James Beck" <jim@reallykillersystems.com> wrote in message > news:MPG.2043d4c48858c892989eba@newsgroups.bellsouth.net... > [snip] > > > > > I guess I'm not getting my head around EXACTLY what you are doing. > > Just keep in mind that bit set and bit clear are RMW instructions and > > you should really be using the latch registers or keep a shadow copy of > > the output data, but why if the output latches do the same thing and you > > don't have the problem of a pin that is a loaded output reading as a 0 > > when it is really driven high (should be treated as a 1). Also, RA4 is > > an open drain output, so it is not driven high by the IC. It may be > > pulled up by the load, but maybe not well enough to read as a 1. Also, > > make sure that any writes to ports you are doing in the main loop can > > not be interrupted by an ISR that may be modifying the same port. > > > > Jim > > > > You were absolutely correct in your first observation that I have been > bitten by the RMW "bug". Now that I have looked carefully at what is > involved when setting or resetting an individual port bit, it becomes very > clear. I changed all my BSF and BCF PORTx instructions to LATx, and all is > well. I kept the btfsc and btfss PORTx instructions as they were because > that is exactly what I want. I think I had a similar problem some time ago, > and I had "fixed" it by maintaining an image of the port data (as in a_data > in my code). I don't know exactly why the code acted as it did, differently > in the test setup and the actual application, but definitely there is a > potential problem reading an open drain pin connected to non-linear loads > like LEDs. > > The datasheet is very vague about this problem. It shows a CLRF LATA as > just an alternate to CLRF PORTA, which it is, but the BSF and BCF > instructions are where problems are likely to occur. There are several > references to this problem that I dug up on the Microchip website, so you > would think they would add a little update on their data sheets to warn > about this. > > I switch back and forth among various projects, including PCB design and > Delphi programming, so it is easy to forget some things like this when I've > been involved in other things for a while. I appreciate your response. > > Thanks, > > Paul
It is easy to forget the "little" things until they become big things. I do most of my PIC work in 'C' (yeah I know, I can hear the grunting and groaning) and the compiler has directives for the IO style, so I tend to just ignore how the IO gets handled. Anyway, no problem, glad things are working now. I can't believe it took until the 18 series for them to add the LATx register. I use to just keep a shadow copy of the port and work on that. Jim
Paul,
Since RA4 is an open-drain output, you cannot drive it high by just setting the port bit.
You need a pull-up resistor (10k is fine) to +5v for that pin only.
This catches a lot of folks.
-Craig


"Paul E. Schoen" <pstech@smart.net> wrote in message news:45d92017$0$6831$ecde5a14@news.coretel.net...
> Hello, > > I am new to this NG, but my question seemed more appropriate here than on > SED. > > I'm using a PIC18F242 for an SCR controller, and programming it in assembly > with MPLAB 7.30. I am using RA4 as an Output On indicator, driving an LED > and an optoisolator through a series resistor to +5VDC. I use RA5 to drive > a status LED, low for green and high for red. > > Everything worked fine when I had the target board connected to a prototype > test setup, but when it was installed in a piece of equipment, the Output > On indicator would latch on sometimes, but would then sometimes work OK > when the output was turned on and off, so it was not a latch-up of the > device. RA4 was being driven low (or not driven high) in software. I found > a few places in my code that could possibly be a loop where the state of > RA4 might not be set high, but I cleaned it up so there was no longer any > possibility, and yet the light still latched on. > > I spent hours trying to find the problem, and sometimes I could get it to > latch up on my test board, but it was always worse in the actual unit where > it was to be installed. I tried removing the 480 VAC supply to the SCRs, > and also powered the board from external 120 VAC power, but the problem > persisted. I also added electrical and software filtering to the initiate > input line, to no avail. > > Finally, I decided to implement a debug version of code that used the RA5 > indicator as a gauge for ISR overhead, setting it at the interrupt and > resetting at exit. I could see that the overhead was OK, on the bench. I > put it in the unit, and also saw no excessive overhead. But the crazy thing > is that now the Output On indicator worked perfectly! > > So, I just set a flag in a file variable in main line code where I wanted > to set or reset the Status LED, and added a check in the ISR to actually > drive the RA5 line. The Output On indicator was still driven as it had been > in the main code loop. > > It works now, but I don't know why. I did not see anything special about > RA4, except that it is open drain and can be connected to a timer. RA5 > seems to be quite ordinary. I am using RA3 as an analog input. I configure > PORTA: > > movlw B'11001011' ;RA<2,4-5> output > movwf TRISA ;W=>TRISA > > Any ideas will be most appreciated. I may make a service ticket to > Microchip unless anyone can point out a cause for this. I may upgrade to a > PIC18F2420, which is similar and recommended for new designs. Maybe there > is a flaw in the 242? > > Thanks, > > Paul E. Schoen > www.pstech-inc.com > >