Reply by Craig Johnson●February 22, 20072007-02-22
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
>
>
Reply by James Beck●February 20, 20072007-02-20
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
Reply by Paul E. Schoen●February 20, 20072007-02-20
"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
Reply by James Beck●February 19, 20072007-02-19
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
Reply by Paul E. Schoen●February 19, 20072007-02-19
"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
Reply by James Beck●February 19, 20072007-02-19
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
Reply by Paul E. Schoen●February 18, 20072007-02-18
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