Searching \ for '[PIC] PIC18F4520 PORTA pins are reseting each othe' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ios.htm?key=port
Search entire site for: 'PIC18F4520 PORTA pins are reseting each othe'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] PIC18F4520 PORTA pins are reseting each othe'
2008\07\30@044944 by Vincent Vega

picon face
Hi,
I have a pic18F4520 in one application with the porta configured as:

clrf PORTA
clrf LATA
movlw    0x07
movwf    ADCON1        ; Disable analog inputs and
movwf    CMCON        ; comparators
movlw    b'11000000'    ; All outputs
movwf    TRISA

The pic is connected to a xc95144 cpld with all inputs in high impedance. The cpld is not affecting the pic because I removed it to check.

Now, when I set up porta,2  everything is OK, when I set up porta,3 the pin RA3 goes high, but for no reasons RA2 resets!
bsf        PORTA,2            ; set pin RA2, "this works OK"
bsf        PORTA,3            ; set pin RA3,  "this also works OK, but RA2 gets reseted!"

If I invert the order, that is RA3 and then RA2, the result is the same. If I write to both at once then everything is OK, but I don't want to do that because I would have to read the port first and save the contents.

movlw   b'11110100'    ; set pin RA2 only
movwf    PORTA
movlw    b'11111100'    ; now, set pin RA3 and keep RA2 high fro previous state
movwf    PORTA            ; This works, most likely because I'm updating the complete contents of the port.

I remember many years ago I read somewhere about inadvertently changing port contents, but I can't remember where. This most probably is some stupid mistake I'm doing, but I don't seem to catch it up. Any ideas?


     

2008\07\30@050938 by Philip Pemberton

face
flavicon
face
Vincent Vega wrote:
> Now, when I set up porta,2  everything is OK, when I set up porta,3 the pin RA3 goes high, but for no reasons RA2 resets!
> bsf        PORTA,2            ; set pin RA2, "this works OK"
> bsf        PORTA,3            ; set pin RA3,  "this also works OK, but RA2 gets reseted!"
>
> If I invert the order, that is RA3 and then RA2, the result is the same. If
> I write to both at once then everything is OK, but I don't want to do that
> because I would have to read the port first and save the contents.

It looks like a read-modify-write issue.

To do a BSF, the PIC reads the current state of PORTA, then modifies it
internally (i.e. setting bit 2 or bit 3), then writes it back out.

Catch: reading PORTA reads the state of the pins. Writing to PORTA sets the
state of the I/O latches.

Try replacing PORTA in those bsfs with LATA -- this will read from and write
to the data latches, not the I/O pins. This is exactly why Microchip added
direct latch access to the PIC18F series - so you didn't have to bother with
shadow registers for output pins :)

> I remember many years ago I read somewhere about inadvertently changing port contents, but I can't remember where. This most probably is some stupid mistake I'm doing, but I don't seem to catch it up. Any ideas?

Google: piclist.com "read modify write"

--
Phil.
spam_OUTpiclistTakeThisOuTspamphilpem.me.uk
http://www.philpem.me.uk/

2008\07\30@051519 by Tamas Rudnai

face picon face
Hi,

> Now, when I set up porta,2  everything is OK, when I set up porta,3 the
pin RA3 goes high, but for no reasons RA2 resets!
> bsf        PORTA,2            ; set pin RA2, "this works OK"
> bsf        PORTA,3            ; set pin RA3,  "this also works OK, but RA2
gets reseted!"

Search for RMW (or Read-Modify-Write) issues in your DataSheet. For short,
you should use LATA as it was PORTA instead of directly modifing to PORTA.

Tamas


On Wed, Jul 30, 2008 at 9:49 AM, Vincent Vega <.....avalon991KILLspamspam@spam@yahoo.com> wrote:

{Quote hidden}

> -

2008\07\30@055636 by Vincent Vega

picon face
Thank you very much Philip!
It worked nicely, but still left me thinking about the entire issue. This is not the first board, actually the third one, with the same firmware running and only this one had that problem. The three IC's were bought from the same supplier, and I suppose are from the same batch, although not necessarily. Why is it that some IC's, two of them, worked with PORTA and one only with LATA? I must say that I left intentionally the PORTB, PORTC and PORTE as such, but those ones worked on fine in all three IC's. Is it possible that the input buffers on RA2 and RA3 are damage somehow? I haven't tried to read from those yet, perhaps that would give a clue.
Anyway, thank you very much again, very appreciated your help and your suggestion.
Regards,
VV



{Original Message removed}

2008\07\30@055923 by Jan-Erik Soderholm

face picon face
Vincent Vega wrote:

> the pin RA3 goes high, but for no reasons RA2 resets!

Check setup of the analog functions.

2008\07\30@063233 by Apptech

face
flavicon
face
> It worked nicely, but still left me thinking about the
> entire issue. This is not the first board, actually the
> third one, with the same firmware running and only this
> one had that problem. The three IC's were bought from the
> same supplier, and I suppose are from the same batch,
> although not necessarily. Why is it that some IC's, two of
> them, worked with PORTA and one only with LATA?


This is one of the sorts of problems that LATA is aimed at.

If you do RMW pin setting, and it fails always or often,
then you learn what's wrong and fix it. But, if you have a
marginal condition that only occasionally fails or that
works for most hardware then you may not find it until far
too late.

Using external real-world-connected pins as stores for data,
which is what RMW instructions are dealing with, is a bad
idea at best and a fatal one at worst. For a practice to be
such a bad idea that Microchip adds a new way of explicitly
preventing it, even though an entirely OK work-around
exists,  gives you some idea of how bad it is.

You are *probably* seeing a real world example of a marginal
condition and are probably not seeing a damaged IC etc. It
may be that this is not the case, but odds are it is.

If you want to learn something more from this experience you
could try to determine loading and coupling capacitances and
signal path impedances to known stiff voltage nodes and try
and see if the situation does in fact appear to be marginal.
If the result is well well away from "the edge" then there
may be another explanation. If it is marginal, trying adding
a small capacitor from ground to the pin concerned on an
example that works. 10 pF may well do but higher won't hurt.
See if that makes a difference. If it turns good to bad it's
probably a good demonstration of a marginal situation.




           Russell McMahon

2008\07\30@070258 by Vincent Vega

picon face
No, it was setup correctly as you could see from the initialization for the port.
Regards,
VV



----- Original Message ----
From: Jan-Erik Soderholm <jan-erik.soderholmspamKILLspamtelia.com>
To: Microcontroller discussion list - Public. <.....piclistKILLspamspam.....mit.edu>
Sent: Wednesday, July 30, 2008 11:59:02 AM
Subject: Re: [PIC] PIC18F4520 PORTA pins are reseting each other for no reasons

Vincent Vega wrote:

> the pin RA3 goes high, but for no reasons RA2 resets!

Check setup of the analog functions.

2008\07\30@071820 by Vincent Vega

picon face
Thanks Russel,
Very good explanation. The pins are connected to a xilinx cpld input and the traces are over a solid ground plane with approximately 100 ohms impedance. The traces are approximately 3/4 of an inch which means ringing of frequencies below 1GHz is excluded, fortunately the PIC doesn't go that high. So, no, it is not any kind of overshoot/undershoot loading the pins. The traces are far from one another to think about cross talk, besides all the other ports go into other directions.
What I did was to switch the IC from the board with problems to a board with no problems, the problem appeared there! I don't know if this is marginal or just plain bad luck, but I do know now that it is a good idea to avoid PORT X to address the ports. I find hard to believe that the IC is broken since when using LATA everything works fine. I'll put the IC aside to investigate later on, this has cost me already 12 working hours and that is far from being funny. Now is time to catch up and try to recover the time I lost.
I appreciate very much all the help you have provided.
My best regards,
VV



{Original Message removed}

2008\07\30@072805 by Tamas Rudnai

face picon face
No, it is not correct I am afraid.

This is the code what is in the DS:

CLRF PORTA ; Initialize PORTA by
; clearing output
; data latches
CLRF LATA ; Alternate method
; to clear output
; data latches
MOVLW 07h ; Configure A/D
MOVWF ADCON1 ; for digital inputs
MOVWF 07h ; Configure comparators
MOVWF CMCON ; for digital input
MOVLW  0CFh ; Value used to
; initialize data
; direction
MOVWF  TRISA ; Set RA<3:0> as inputs
; RA<5:4> as outputs

However, 0x07 to ADCON1 will switch off analogues only on PORTB as you can
read it later on register 19-2 / ADCON1:

PCFG3:PCFG0
...
0111 DDDDDAAAAAAAA
...
1111 DDDDDDDDDDDDD

Tamas
PS: Have you guys noticed the "MOVWF 07h ; Configure comparators" in the
init example of PORTA in that DS?




On Wed, Jul 30, 2008 at 12:02 PM, Vincent Vega <EraseMEavalon991spam_OUTspamTakeThisOuTyahoo.com> wrote:

{Quote hidden}

> -

2008\07\30@083147 by Jinx

face picon face
> However, 0x07 to ADCON1 will switch off analogues only on
> PORTB as you can read it later on register 19-2 / ADCON1:
>
> PCFG3:PCFG0
> ...
> 0111 DDDDDAAAAAAAA
> ...
> 1111 DDDDDDDDDDDDD

I've b**ched to Microchip about that one. Wasted a couple of my
hours on someone's sloppy Copy/Paste from the 452 manual

> PS: Have you guys noticed the "MOVWF 07h ; Configure
> comparators" in the init example of PORTA in that DS?

Oh yes. Every Microchip code example is suss until proved otherwise

2008\07\30@094253 by Jan-Erik Soderholm

face picon face
>
> ----- Original Message ----
> From: Jan-Erik Soderholm <KILLspamjan-erik.soderholmKILLspamspamtelia.com>
> To: Microcontroller discussion list - Public. <RemoveMEpiclistTakeThisOuTspammit.edu>
> Sent: Wednesday, July 30, 2008 11:59:02 AM
> Subject: Re: [PIC] PIC18F4520 PORTA pins are reseting each other for no reasons
>
> Vincent Vega wrote:
>
>> the pin RA3 goes high, but for no reasons RA2 resets!
>
> Check setup of the analog functions.
>



Vincent Vega wrote:
> No, it was setup correctly as you could see from the
> initialization for the port.
> Regards,
> VV
>

OK, didn't check closely...

BUT, in 99 out of 100 of the cases where pins behave as
you described, it's due to that the analog functions are
*not* disabled. And later posts seems to verify this, some
error in the datasheet if I understand what it was about...

Best Regards,
Jan-Erik.


2008\07\30@095522 by PAUL James

picon face

Philip,

It seems to me that LATA is a shadow register.

Jim

-----Original Message-----
From: spamBeGonepiclist-bouncesspamBeGonespammit.edu [TakeThisOuTpiclist-bouncesEraseMEspamspam_OUTmit.edu] On Behalf
Of Philip Pemberton
Sent: Wednesday, July 30, 2008 4:09 AM
To: Microcontroller discussion list - Public.
Subject: Re: [PIC] PIC18F4520 PORTA pins are reseting each other for no
reasons

Vincent Vega wrote:
> Now, when I set up porta,2  everything is OK, when I set up porta,3
the pin RA3 goes high, but for no reasons RA2 resets!
> bsf        PORTA,2            ; set pin RA2, "this works OK"
> bsf        PORTA,3            ; set pin RA3,  "this also works OK, but
RA2 gets reseted!"
>
> If I invert the order, that is RA3 and then RA2, the result is the
same. If  > I write to both at once then everything is OK, but I don't
want to do that  > because I would have to read the port first and save
the contents.

It looks like a read-modify-write issue.

To do a BSF, the PIC reads the current state of PORTA, then modifies it
internally (i.e. setting bit 2 or bit 3), then writes it back out.

Catch: reading PORTA reads the state of the pins. Writing to PORTA sets
the state of the I/O latches.

Try replacing PORTA in those bsfs with LATA -- this will read from and
write to the data latches, not the I/O pins. This is exactly why
Microchip added direct latch access to the PIC18F series - so you didn't
have to bother with shadow registers for output pins :)

> I remember many years ago I read somewhere about inadvertently
changing port contents, but I can't remember where. This most probably
is some stupid mistake I'm doing, but I don't seem to catch it up. Any
ideas?

Google: piclist.com "read modify write"

--
Phil.
RemoveMEpiclistspamTakeThisOuTphilpem.me.uk
http://www.philpem.me.uk/

2008\07\30@101958 by Philip Pemberton

face
flavicon
face
PAUL James wrote:
> Philip,
>
> It seems to me that LATA is a shadow register.

True. But what I meant was that on the PIC18 series, you don't have to use a
file register (RAM byte) for each port you're shadowing, unlike the PIC12 and
PIC16 series (which don't have the LATx shadow registers).

--
Phil.
piclistEraseMEspam.....philpem.me.uk
http://www.philpem.me.uk/

2008\07\30@102822 by Vincent Vega

picon face
I'm afraid that you didn't read the original mail. The following is the code I posted:

clrf PORTA
clrf LATA
movlw 0x07
movwf ADCON1 ; Disable analog inputs and
movwf CMCON ; comparators
movlw b'11000000' ; All outputs
movwf TRISA

As you can see this does exactly the same as the one you posted, well almost, I didn't include the instruction MOVWF 07h as you can see. Since WREG was already loaded with 0x07 there was no need to do it again. I read the port setup from the datasheet, actually the code you copied and pasted below.

What should one believe is correct? Probably, to load ADCON1 with 0x0F instead of 0x07. Well, I did miss that one, but it still doesn't explain why it works on one IC and not on the other. Is it possible that nobody else has stumbled into this before in the PICLIST?

I appreciate that you took your valuable time and tried to help me.
Have a nice day
Vincent Vega



{Original Message removed}

2008\07\30@103534 by Vincent Vega

picon face
Yes, there's an error that Tamas pointed out. Check the ADCON1 on section 19-2 of the PIC18F4520 datasheet.  It seems like one should load 0x0F into ADCON1 instead of 0x07 as suggested by the datasheet in the PORTA section 10 example 10-1. But, what is not right is the fact that the same code works in one IC and not in the other, that's what keeps me confused.
Best Regards and enjoy the summer it seems like we finally are going to have one this year after all the rain and cold weather, well the vacations are gone anyway!
Vincent Vega



{Original Message removed}

2008\07\30@105134 by Vincent Vega

picon face
Setting up the ADCON1 to 0x0F didn't change anything!! As long as the pins are accessed as bsf PORTA,2 it doesn't work no matter if you load 0x07 or 0x0F into ADCON1. However, accessing the pins as bsf LATA,2 cures the problem completely. Now I'm really confused, I believed for a moment that the mistake in the datasheet could explain the error, well, I was wrong. Arrgh...
Regards,
VV


{Original Message removed}

2008\07\30@110649 by Alan B. Pearce

face picon face
>Yes, there's an error that Tamas pointed out. Check the ADCON1 on
>section 19-2 of the PIC18F4520 datasheet.  It seems like one should
>load 0x0F into ADCON1 instead of 0x07 as suggested by the datasheet

And what happens when you do this with the PIC that doesn't work ???

2008\07\30@111051 by Tamas Rudnai

face picon face
> As long as the pins are accessed as bsf PORTA,2 it doesn't work no matter
if you load 0x07 or 0x0F into ADCON1. However,
> accessing the pins as bsf LATA,2 cures the problem completely.

Hang on a minute. There was two issues, one with port init and the other
with the RMW issue. Now you are talking about this latter one. LATA cures as
it should cure the RMW problem, that's why it was invented on 18F family -
it is a bit more pain in mid-range and base line as well. Anyway, the
success of two or more consequent RMW instruction to a port depends on the
load of the pin basically, how fast the PIC can change the line... Use LATA
all the time to avoid any problems + read about the RMW issues as I
mentioned earlier.

With the port initialization, well, I believe that 07h is wrong, however,
you can read this sentence in the DS which explains why it works for you at
the moment:

"The analog input channels must have their corresponding TRIS bits selected
as an input. "

Tamas



On Wed, Jul 30, 2008 at 3:51 PM, Vincent Vega <EraseMEavalon991spamyahoo.com> wrote:

> Setting up the ADCON1 to 0x0F didn't change anything!! As long as the pins
> are accessed as bsf PORTA,2 it doesn't work no matter if you load 0x07 or
> 0x0F into ADCON1. However, accessing the pins as bsf LATA,2 cures the
> problem completely. Now I'm really confused, I believed for a moment that
> the mistake in the datasheet could explain the error, well, I was wrong.
> Arrgh...
> Regards,
> VV
>
>
> {Original Message removed}

2008\07\30@111936 by Jan-Erik Soderholm

face picon face
Vincent Vega wrote:

> Setting up the ADCON1 to 0x0F didn't change anything!!
> As long as the pins are accessed as bsf PORTA,2 it
> doesn't work no matter if you load 0x07 or 0x0F into ADCON1.

Is that with *no* load connected to the physical pin ?
That is, open pins set as output ?
What if you add 2 or 3 NOP's between the two BSF's ?
That often cures capacitively introduced RMW problems.

> However, accessing the pins as bsf LATA,2 cures the
> problem completely.

Yes it does, both in the case of wrongly setup analog
functions *and* heavily loaded output pins. It doesn't
say which of them it was/is.

> Now I'm really confused, I believed for a moment that
> the mistake in the datasheet could explain the error,

So did I.

You're sure that you realy re-loaded the PIC with the
new code ? Also a common error... :-) :-)

One thing you could verify, is if you can read the
same "value" (that is "0" or "1") from PORTA,2 and
LATA,2 after setting the LATA, 2 = "1". Use BTFxx
that doesn't write anything back to the registers.
If you *always* read PORTA, 2 as "0", I'd say that
you still have the pin set as analog...

Jan-Erik.

2008\07\30@113428 by Vincent Vega

picon face
Nothing happens, still doesn't work.
Regards,
VV



----- Original Message ----
From: Alan B. Pearce <RemoveMEA.B.PearceEraseMEspamEraseMErl.ac.uk>
To: Microcontroller discussion list - Public. <RemoveMEpiclistspam_OUTspamKILLspammit.edu>
Sent: Wednesday, July 30, 2008 5:06:10 PM
Subject: Re: [PIC] PIC18F4520 PORTA pins are reseting each other for no reasons

>Yes, there's an error that Tamas pointed out. Check the ADCON1 on
>section 19-2 of the PIC18F4520 datasheet.  It seems like one should
>load 0x0F into ADCON1 instead of 0x07 as suggested by the datasheet

And what happens when you do this with the PIC that doesn't work ???

2008\07\30@120722 by Vincent Vega

picon face
Yeah, there might be two issues, but the result is the same. I understood what you're saying about the input channels TRIS bits correctly selected, but I still have to point out to the fact that the same code works for two ICs flawlessly.
There's no heavy load to the PIC, the traces are minimal and placed over a ground plane. With around 3/4 of an inch in length and 10mil width you end up with approximately 15pF of load. Add to that value the loading from the CPLD, which is around 10pF and you end up with approximately 25pF. The datasheet for the 4520 says it can easily drive 50pF from all I/O pins except the OSC2 pin. So, you can safely put to rest the theory of heavy loading and the pic changing the line etc. Further more, I don't believe the modify is the one failing here but the read part of RMW. As you probably noticed I used the PORTA instruction instead of LATA, it is because I have *never* had any problems with it. That includes the 12C, 16C & F and 17C series, so I don't know the pain you are referring to, but I guess I'm just lucky.
I also believe the 0x07 is wrong, but until I got an answer from my local Microchip rep I'll stick with the 0x0F for the moment. It just makes more sense, but not necessarily right after all it is taken from the same datasheet that loads WREG into 0x07!!
Something must be wrong, but besides the suggestion from Russel I don't see how to cope with these issues in the future. Your explanations, while interesting and sound, haven't brought much light to the problem. None the less I do appreciate the time you take to clarify this.
My best regards
Vincent Vega



{Original Message removed}

2008\07\30@123540 by Vincent Vega

picon face
Hi Jan Erik,
I tried with and without the cpld connected, same results. Although, I didn't expect anything else, the cpld is a very light load. I did try the NOP's trick, as you said is an old trick, and no, it didn't work. The setup analog was discarded by the fact that I did reload the pic with the new code, actually the MPLAB IDE always pick the last compiled version so no chance in there.
The load to the outputs, well, I don't think so, the load is minimal and should no pose any problems at all.
To your last suggestion, I checked out that ADCON1 was indeed loaded with 0x0F and then I did like this:
bsf LATA,2
btfss PORTA,2
nop
btfss LATA,2
nop
ran it with the ICD2 and when reading from PORTA,2 it reads "0", when reading from LATA,2 it reads "1", but the ADCON1 is loaded with 0x0F!! Does it make any sense to you? You see, I don't care about one IC, I can toss it and get another one. What I cannot afford is having units coming back from the customers because they all of a sudden stopped working at all. Is this a one IC problem? Little by little I'm starting to believe it is. If you look at the diagram 10-1 of the datasheet it looks that Read PORTA actually reads from the physical pin, while Read LATA reads from the output flop. What if these particular IC input buffers decided to go on strike on me? A different matter, this happens only with RA2, RA3 and RA5 the rest are OK. With every minute I'm getting closer and closer to my hammer.
Even if it is a one IC problem, I'm glad that I decided to dig into it because I believe Tamas is right about the 0x0F and the ADCON1. That can be very useful to know.
Regards,
Vincent Vega



{Original Message removed}

2008\07\30@132230 by Jan-Erik Soderholm

face picon face
Vincent Vega wrote:
> Hi Jan Erik,
> The load to the outputs, well, I don't think so,

Neither do I, with what you have described.

> and when reading from PORTA,2 it reads "0",
> when reading from LATA,2 it reads "1",...

As long as they don't read the same, *something*
is wrong. Maybe with just *that* chip...

Now, if it's just chip and you're absolutely unable
to reproduce it on another chip, well, where is
the problem ? :-) :-)

Jan-Erik.

2008\07\30@144628 by Vincent Vega

picon face
Yes, you are probably right, I should dump this and continue. It was, as always, very rewarding to  post to the piclist and read  your answers and your suggestions. Thank you all for your excellent help. As soon as I'll hear from the Microchip rep I'll post here the answer.
Regards,
Vincent



{Original Message removed}

2008\07\30@164243 by Tamas Rudnai

face picon face
I think you might miss the point with the "NOP trick". First of all the NOP
is only a timing which may or may not cure the problem as the line may or
may not raise high by the time the NOP is executing. Secondly you did _not_
put NOP in between writing to the port and testing it.

Your code is:

bsf LATA,2
btfss PORTA,2   ; this is the very next instrucion to BSF so there is no NOP
in between!
nop                   ; (and does not matter if you were using LATA or PORTA
for BSF... )
btfss LATA,2     ; this is only reading the shadow, so of course it will be
always as intended...
nop

but I think it rather should look like as a test:

bsf LATA,2
btfss PORTA,2    ; this may or may not fail
nop
btfss PORTA,2    ; now this is the 3rd instruction since BSF, so it's like 2
NOPs in between...
nop                     ; more likely to succeed...

If I were you I'd write something like this (after the port init os course):

bsf LATA,0
bsf LATA,1
bsf LATA,2
bsf LATA,3
bsf LATA,4
goto $

...try the same test with PORTA ...
...and put LEDs on each pin to see if everything is ok - I would forget ICD2
debugging for the moment.

Just for clarification, reading LATA is only for experimenting purposes, in
real applications polling input pins are still should going through PORTA as
LATA is only an output latch register. When you write the LATA or PORTA, the
very next instruction happens to be too soon to be able to raise the pin
high. So I am not surprised that BTFSS failed. That's exactly why you are
going to use LATA... as LATA does not depend on the PORT pin, so writing to
LATA and reading it at the very next instruction will show the value you put
on it - while PORTA may still show something else.

Best regards,
Tamas



On Wed, Jul 30, 2008 at 5:35 PM, Vincent Vega <RemoveMEavalon991TakeThisOuTspamspamyahoo.com> wrote:

{Quote hidden}

> {Original Message removed}

2008\07\30@182654 by Vincent Vega

picon face
Tamas, the IC *was* the problem, the code was OK either way. As Russel commented, the IC is probably not broken, but having some *issues*. The way to go to avoid *issues* is to use LATA, I put the board with the *lazy* IC aside and will try to load small capacitances to see if the marginal condition Russel is taking about takes place.

I got 12 more boards assembled and tested this afternoon and all worked fine with PORTA or LATA. However, to be on the safe side I left the LATA/LATB instructions for port outputs and PORTB for inputs since I don't have any inputs on PORTA. I have 88 more boards to go, I think in a couple of days I'll have pretty good idea of what works and what doesn't with this stuff.

Thanks for the time you took reading my comments.
Best regards,
Vincent Vega



{Original Message removed}

2008\07\30@205854 by Tamas Rudnai

face picon face
Vincent,

I am trying to help you, so please take a bit more attention of wording.
That is what Russel said:

> If you do RMW pin setting, and it fails always or often,
> then you learn what's wrong and fix it. But, if you have a
> marginal condition that only occasionally fails or that
> works for most hardware then you may not find it until far
> too late.

And that's exactly what I am talking about too :-) Just wanted to make sure
you understand the problem, because it is *not* an "issue of one or two
badly produced chip" on Microchip factory. It is a well known issue for
virtually *all PICs*, all that are already sold or produced, and probably
all that on the design phase too. Russell *did not* say that this is an
issue with the IC or whatever. He said that

> You are *probably* seeing a real world example of a marginal
> condition and are probably not seeing a damaged IC etc. It
> may be that this is not the case, but odds are it is.

It means to me that there is no two fully identical ICs - of course there is
no any, as there is no identical resistor, capacitor, transistor etc. One
may can work with that consequent PORTA manipulation while the other one
does not. And temperature changes and everything can changed. Now your 3rd
PIC works strange, at the customer side maybe 1st and 2nd. The Vdd changes
or a little EMI and it also changes everything and your 45th of panel will
stop working correctly. You cannot tell which IC is good in that way. That's
normal, it is well known issue with PICs, do not panic. Your job is to count
on it and write a firmware that aware of this well known issue. As you said
"be on the safe side":

> I left the LATA/LATB instructions for port outputs and PORTB

Yes, that is exactly the solution, that is how Microchip helps us with this
issue - which was non-existent on mid-range but on 18F and is very
convenient as all we have to do is to address LATA instead of PORTA and the
problem is eliminated. But in your test code you were using BTFSS PORTA at
the very next instruction to BSF LATA which is just as bad as two consequent
BSF PORTA...

If you think it over, to write to LATA is virtually the same as to write to
PORTA. The big difference is *reading* of it. So you write BSF PORTA,0 which
changes only one bit, but PIC reads the *entire* PORTA, modifies and writes
it back. But when you set bit 0 like this, it may not raise the signal fast
enough, so when you say BSF PORTA,1 it reads the entire PORTA while bit 0 is
still low. Now you set bit 1 high, but bit 0 is low, and then BSF writes the
enitre port back... Therefore bit 1 is high, but bit 0 is low... That's a
typical RMW issue.

Same happenes with BSF LATA,0 ... BTFSS PORTA,0 -> PORTA,0 still low while
you BTFSS on it... That's let's say a non-trivial RMW issue... It does not
alter PORTA as in the typical RMW example, PORTA,0 will be still raise to
high sometime later on, however, your code will fail with that BTFSS. It is
not a real issue, however, as it is quite silly to do that (BSF and then
BTFSS on the same bit). It could happen that you have a bit mask in WREG and
then a XORWF / ANDWF / IORWF etc on PORTA, or if there is a jump to the
BTFSS from somewhere, so might existing this in a real firmware.

When you are doing it with LATA, BSF reads LATA instead, modifies it and
writes back to LATA. Nothing to do with PORTA. So PORTA,0 is still low, but
LATA,0 is high, so reads LATA with bit 0 high, modifies it to both bit 1 and
0 high then writes back to LATA. That's why it works always while doing the
same with PORTA is unpredictable. Once you understand this behaviour then
you will never ever face to this problem again - or can solve it quickly.

Anyway, best luck for your project.

Tamas



On Wed, Jul 30, 2008 at 11:26 PM, Vincent Vega <EraseMEavalon991spamspamspamBeGoneyahoo.com> wrote:

{Quote hidden}

> {Original Message removed}

2008\07\31@040650 by Vincent Vega

picon face
Tamas,
Thanks again for trying to help, as I said, it *was* the IC, I have this morning tested 37 more boards and all check OK. Your scenario is unlikely to happen because in my code, I do not address two pins sequentially, you fail to understand that. On *that* IC I merely set a pin and then the other pins RA2, RA4 or RA3 depending on the one I was addressing got reset, but pay attention now, it was already set from before in the code no at the previous instruction.

Your explanation is very eloquent, but except of what Philip said it doesn't offer any other solution. Understanding poor design from the Microchip side is not part of my business, but finding a work around is. The btfss thing was a test that Jan Erik suggested, perhaps adding a few NOPs after the bsf LATA,2 would have been appropriated, but face it, it doesn't deal with the issue I posted because the pins that are reseting were high for long time ago.

I never understood what you are saying about a *line going high* and the PIC not catching up. I believe you need to reconsider your own statement, because in this context it doesn't make any sense. Besides, even if it would the *line* was already high because it was set long ago in the code. Lines don't go high as slow as you imagine if there's no substantial amount of  capacitive loads, remember the PIC can deliver up to 20mA on its pins. Now, how long would it take for the PIC to put 25pf to 3.3V with say 15mA current? Do you really believe this is an issue?

Regarding the Vdd and EMI problems, well, how do you bypass your circuits? I personally prefer to put a LP298xx right next to the chip with beefy caps giving me a good night sleep while my units work safely around the clock. So, sorry, No, I do not gamble with stuff that I sell so far away from where I live. The EMI problem, if you read my previous post you'll see that I do check for signal integrity and work with safe EMC design. That is also an important issue, because if the units don't pass the FCC certification, and they did, then I cannot sell them.

I understand that you were trying to help, but it is important to understand the problem you are trying to help with in order to be able to do so. I never, believe it or not that's the truth, have had any problems with a pin doing silly stuff like the one that IC pull on me. I started with PICs in 97 and got used to the setting PORTA, BANKSEL and all those stuff, and with the 18 series; I continue doing what I was used to, of course. Now, that Philip and Russel pointed out that the way to go is to use LATx for outputs and PORTx for inputs, then that's the way it will be done. Only the previous sentence matters, the rest is theoretical approach and guess work about lines going high or low. That doesn't help at all, a solution does, and the solution was given by Philip and Russell, thank you very much.

I find the diagram 10-1 in the datasheet very instructive, and I suggest you to take a look at it and reconsider your statements.

My best regards and wish you luck with your projects.

Vincent Vega





{Original Message removed}

More... (looser matching)
- Last day of these posts
- In 2008 , 2009 only
- Today
- New search...