Pics and Hex Code
Trevor Bentley
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
Mike Harrison
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.
Spehro Pefhany
<Tre...@p-m-services.co.uk> wrote:
>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.
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.
>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.
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
Jonathan Kirwan
<Tre...@p-m-services.co.uk> wrote:
>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.
I use quite a few of the PIC16C73B's. Familiar with them.
>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 gather you don't have the source code for this. So it's
difficult for you to experiment and track this down, internally.
>I have swopped GOOD and BAD PICs between different units and the fault
>follows the pic.
Very interesting.
>I have bought some Flash devices to try and experiment with but these
>also show same effect.
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."
>Can anyone shed any light?
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
Jonathan Kirwan
the PIC16C63 and see what happens there.
Jon
Tim Shoppa
> Can anyone shed any light?
Floating inputs causing undesired interrupts?
Device not verified at operating Vcc?
Tim.
jim
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
"Trevor Bentley" <Tre...@p-m-services.co.uk> wrote in message
news:nzo7BZAb...@p-m-services.co.uk...
EEng
<Tre...@p-m-services.co.uk> wrote:
>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
Seems to me you've answered your own question already. If the fault
follows the one PIC, its bad. Throw it away.
Tim Shoppa
> I gather you don't have the source code for this. So it's
> difficult for you to experiment and track this down, internally.
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.
Spehro Pefhany
(Tim Shoppa) wrote:
<snicker> Yes, nothing like misleading source comments to let you miss
something right in front of you.
Trevor Bentley
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 <nzo7BZAb...@p-m-services.co.uk>, Trevor Bentley
<Tre...@p-m-services.co.uk> writes