Anyone PLEASE !!??!!

I have Hex code for PicC73B and have been programming others from that
for a long while using MPLAB and a picstart programmer with Config bits
and Processor set correctly.

Last batch of twenty some working ok others seem ok but program itself
appears to run slower ( using scope ), in particular PortC I2C which
having read bits from 24c04 is driving an 8 bit expander to an LCD
display. The correct text strings appear along with lots of odd
characters.

I have swopped GOOD and BAD PICs between different units and the fault
follows the pic.

I have bought some Flash devices to try and experiment with but these
also show same effect.

Can anyone shed any light?

Remember to remove NOSPAM in return...

Thanks Trevor  
--
Trevor Bentley
P+M Services (R) Ltd     Tel :  01706 815212    Fax : 01706 818636
Http://www.p-m-services.co.uk

One possibility is that the crystal is oscillating in an unwanted mode, due to incorrect loading
caps.

Otherwise there may be a marginal timing somewhere that's causing the watchdog to unexpectedly trip
- the WDT frequency has a pretty loose spec.

It could also be down to marginal timing on a port read/modify/write operation, small variations in
pin loading causing incorrect data to be read back.

On Wed, 30 Apr 2003 10:59:55 +0100, the renowned Trevor Bentley

Maybe the PIC is actually faster and it is showing up some race
condition in your expander circuit. Double check every detail of the
timing against the data sheet worst case conditions on the port
operating from your code. Especially at 20MHz you may need some NOP
instructions in there.

Something like the 16F73 would probably be faster than older devices.

Best regards,
Spehro Pefhany
--
"it's the network..."                          "The Journey is the reward"
sp...@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

On Wed, 30 Apr 2003 10:59:55 +0100, Trevor Bentley

I use quite a few of the PIC16C73B's.  Familiar with them.

I gather you don't have the source code for this.  So it's
difficult for you to experiment and track this down, internally.

Very interesting.

I'm assuming here that you are building a product, using a
binary image, and that you aren't a computer programmer type.
Also that your production methods are just the same as before
and that, so far as you can tell, every part and method used is
just the same.  And that, finally, using the same practices and
parts, it appears that the device no longer does what it once
did -- using "bad PICs."

It's weird, given what you've said.  You've eliminated the issue
of other parts on your board, because you've demonstrated that
the problem goes with the bad PIC to the any board.  (And, I
assume, that the lack of a problem similarly follows the good
PICs.)

A few immediate things cross my mind, with that in mind --

(1) Your binary image isn't the same, for some reason.  This
would explain your experience, certainly.  Is there any way you
can read out the contents of your good PICs and then also read
out the contents of your bad PICs and just verify that the
contents of both (including fuses) is identical?  This would be
a double-check, just cross-verify that something hasn't happened
to the programming module, or your procedures, or your binary
file.

(2) Microchip has made some "minor" change, or bug fix, or else
introduced a new bug in their silicon which doesn't affect much
(they imagine), except that it is affecting you.  It wouldn't be
the first time.  This may explain your experience, with both C
and F type parts, because they may made a "bug fix" on both,
rev'ing them.  Can you check the numbering on your parts, good
and bad, and notice similarities in the date codes for the bad
parts?  What is all the numbering you can see on the new C and F
parts and what is the numbering on the "good" PICs?

If they've rev'ed the parts and this is causing your problem,
you may need to find only older parts for your use or else get
at the source code to discover and then recode a fix to the
software.  Of course, recoding could be tough if you don't have
the sources.  If the binary images in the parts aren't the same,
then you need to re-set your procedures to load the correct
binary.

Jon

Also, if you don't need the ADC, you might also experiment with
the PIC16C63 and see what happens there.

Jon

Floating inputs causing undesired interrupts?

Device not verified at operating Vcc?

Tim.

Hi,

    We had a problem with a 16C57. We checked with the distributor if we
could use a 16C57C in place of a 16C57XTP (which was out of stock). they
thought it was no problem. The 16C57Cs programmed OK but failed in the field
(can't remember the problem..something to do with reseting/shut down). The
point is make sure you are using *exactly* the right part.

Check that the crytal freqency is equal to, or less than, the chip max
freqency. If uChip have revised the silicon it may be that an overclocked
PIC may now show up faulty.

Check the loading caps on the crystal are correct.

Scope the crystal to check that it is running stable, and at the correct
frequency.

Ask your local Microchip agent to verify your chips (and/or program a batch
of them) with a Promate programmer (they should have one). That'll rule out
the Picstart - they can be tempermental.

Cheers

Jim

news:nzo7BZAb65r+kA+T@p-m-services.co.uk...

On Wed, 30 Apr 2003 10:59:55 +0100, Trevor Bentley

  Seems to me you've answered your own question already.  If the fault
follows the one PIC, its bad.  Throw it away.

As you've pointed out, the OP probably chose to be in a position of
ignorance with respect to the source code.  That said, it is incredibly
easy to disassemble PIC hex files into assembly opcodes (sans comments,
of course).  And with the typical poor quality of PIC source code,
the assembly opcodes may be just as good as having the true source!

Tim.

On 1 May 2003 03:27:33 -0700, the renowned sho...@trailing-edge.com

<snicker> Yes, nothing like misleading source comments to let you miss
something right in front of you.

Best regards,
Spehro Pefhany
--
"it's the network..."                          "The Journey is the reward"
sp...@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

Thanks to all that replied to my PIC problem.

The code was written by me over three years ago (probably using "A"
version chips ),at another company and we now assemble that product
where I work now. I have got hold of the source code and following the
trend of most replies have been playing around with timings.  
Multiple Single characters could be "putxlcd" to the lcd via the I2C,
but building a string and "putslcd" to the lcd was the problem.

Changing the string function to single character function works fine now
with B and F versions, so without spending too much time discovering
exactly where the problem occurs this FIX will do fine.

Thanks again to all that hinted at this route.

Regards.

In article <nzo7BZAb65r+k...@p-m-services.co.uk>, Trevor Bentley
<Tre...@p-m-services.co.uk> writes

--
Trevor Bentley
P+M Services (R) Ltd     Tel :  01706 815212    Fax : 01706 818636
Http://www.p-m-services.co.uk