Searching \ for '[PIC]: 16F877 Problem Part Two' 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/devices.htm?key=16F
Search entire site for: '16F877 Problem Part Two'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: 16F877 Problem Part Two'
2001\07\18@145409 by Barnaby Thieme

flavicon
face
I sincerely thank everyone who responded to my query.

Dan: Yes, I am using RB0 to indicate reception of a start byte.  This is
working fine with the 67, and I don't believe there's any changes to RB0 on
the 877.  Do you have any ideas?

Olin: We are aware of the increased capacitance issue caused by the socket
module.  It has always caused trouble when emulating with the board
resonator, so we are forced to emulate with the PC clock.  I highly suspect
that my 232 problem is timing-related.  However, I am bewildered by the fact
that this code works on the 67 (see postscript if interested) but not on the
877.  Presumably whatever capacitance issues arise for the one should affect
the other as well....   (BTW I'm aware that some of my initialization code
is unnecessary -- I figured it couldn't hurt.)

Jerry: I have done a close comparison, register by register, bit by bit, of
the differences between the two processors.  I believe all differences are
addressed by my initialization routine.  Thank you for the suggestion of
randomizing variable initialization -- I'm proceding with that now.

I have talked to Microchip and they suggested that this problem might be
related to the silicon errata issue pertaining to TMR1 on the 877.  TMR1 is
not set to extermal clock mode in my application, so I have eliminated that
as a possible candidate.

If anyone has any thoughts or ideas I would love to hear them.

A million thanks,

Barnaby Thieme
Product Engineer, SP Controls, Inc.
(415) 642-2600 ext. 108
spam_OUTbthiemeTakeThisOuTspamspcontrols.com

PS My method to test this code on the 16C67 has been to comment out the
additional initialization code I added in service of the 877 and to
substitute nop's so that code length would be identical.  When this code is
burned on a 67, it functions without any problem.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\07\18@165338 by Mike Mansheim

flavicon
face
> If anyone has any thoughts or ideas I would love to hear them.

If you are using RB3, have you disabled LVP?
I did a quick test - the emulator does not care about this fuse
setting (like the WDT), but the programmed chip does.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\07\18@175958 by Heinz Czychun

flavicon
face
At 11:52 AM -0700 7/18/01, Barnaby Thieme wrote:
>I sincerely thank everyone who responded to my query.
>
>...<snip>....
>
>If anyone has any thoughts or ideas I would love to hear them.
>
>A million thanks,
>
>Barnaby Thieme
>Product Engineer, SP Controls, Inc.
>(415) 642-2600 ext. 108
>.....bthiemeKILLspamspam@spam@spcontrols.com
>
>PS My method to test this code on the 16C67 has been to comment out the
>additional initialization code I added in service of the 877 and to
>substitute nop's so that code length would be identical.  When this code is
>burned on a 67, it functions without any problem.
>
       With all due respect to the emulator, could the additional (
initialization ) code have pushed the program over a page boundary,
that is not properly handled by the isr or other subroutine ?????
       I'm not sure how similar the memory maps are between the 'C67
and 'F877, so I may be talking through my hat, but I seem to remember
someone had started their registers too low in memory.

Just some way out thoughts,
Heinz

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


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