Searching \ for '[pic]Pic Silicon Bugs' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/microchip/devices.htm?key=pic
Search entire site for: 'Pic Silicon Bugs'.

Exact match. Not showing close matches.
PICList Thread
'[pic]Pic Silicon Bugs'
2006\12\08@200610 by Genome

picon face
I've heard of people having trouble with pic's that seem to have silicon
bugs in them.. can anybody post pic's that we should watch out for when
buying....

I was going to buy a pic18f1320 and use it for some serialport communication
with a PC.. but doing some googling I accidentally come across in the
microchip forum that this pic has a USART bug... this may not be true but I
did not want to risk it and go for a differnt pic.. I did not want to waste
my time doing lots of work only to find out that a pic.. will not work as
published...



2006\12\08@204715 by Carl Denk

flavicon
face
As one newbie to another (assuming)(and not knowing your background,
experience, schooling, etc. (the drawback to E-mail))  to the PIC world
with a one off application for the 18F1320, it has been a bunch of
grief. I have been able to get the USART to work OK at 9600 RS-232 with
either 8mhz or 20 mhz.

The silicon bugs (if you can believe thats all of them) are listed, see
the datasheet web page, right side, and probably for your application is
a non-issue.

If planning Assembler and familiar with that, shouldn't be a problem. If
somewhat familiar with "C" and planning to use that, I believe that's a
deep hole. The actual "C" isn't such an issue, as the compiler quirks,
in particular casting variables (memory models, rom, ram, near, far,
etc.). The real problem the manuals have the needed info scattered all
around:

C18 manual > Chapter 2, and Diagnostics
Getting Started > Chapter 4, FAQ's 4 and 15
Numerous places I have seen suggested to recompile the librarys as
'near', but the details of how to do it are lacking, and help is scarce.

as just a few.

If new to the game should think of another direction. Check the software
first to ensure it supports the chips and peripherals you plan on using.
If cost is no object probably Micro Engineerings Pro Basic compiler
might be a good choice. My application is 3 ADC sensors, send the data
out a fiber optic link to RS-485 to a PLC when requested. Sounds simple,
been a hassle. I looked back in the Aztec C-86 (Intel 8086 chip), and
for even moderate programs, all straight forward "C", basically wrote
per K & R and it ran.


At the moment wrestling with printf of a small unsigned char string
array thats in idata with Far memory models, even though the 1320  
doesn't come near the near limits. You can take examples, cut an paste
from the manuals or even straight files and they probably require
tweaking to run.

:(


Genome wrote:
{Quote hidden}

2006\12\08@212028 by Tony Smith

picon face
> I've heard of people having trouble with pic's that seem to
> have silicon bugs in them.. can anybody post pic's that we
> should watch out for when buying....
>
> I was going to buy a pic18f1320 and use it for some
> serialport communication with a PC.. but doing some googling
> I accidentally come across in the microchip forum that this
> pic has a USART bug... this may not be true but I did not
> want to risk it and go for a differnt pic.. I did not want to
> waste my time doing lots of work only to find out that a
> pic.. will not work as published...


Find the errata sheet (at Microchip) for the version you have, it will state
any known bugs (that the company is will to admit to) and workarounds.
Check the datasheet, make sure you get the latest version.

The easiest way is to stay off the bleeding edge, and wait for the mext
revison to come out.  Easy for a hobbyist, not so easy for the pros.
Occasionally hobbyists will get caught out by vendors selling 'old stock'.
There's a reason they were cheap.

Look thru the PicList archive for people complaining (or Google).  18f1320
and the usual keywords (bug, errata, sucks, fails, problem, error etc) will
turn up something.

Tony

2006\12\11@044356 by Alan B. Pearce

face picon face
>The easiest way is to stay off the bleeding edge,
>and wait for the mext revison to come out.

Doesn't always work out that way for a couple of reasons ...

1. Microchip seem to reuse the VHDL for individual modules between all
processors in a family, but the support teams for individual chips don't
seem to talk to each other. See the recent thread where )IIRC) Bob Blick was
having a problem with EEPROMs in a 12F series chip, and I pointed him at
what sounded like a similar problem in 16F627/8 chips, but it wasn't noted
as an errata for the 12F chips he was using.

2. There is no way of knowing when Microchip change the silicon revision
until you actually purchase chips and check the revision. So you could wait
forever without knowing if they even fixed the bug ...

2006\12\11@070411 by Bob Axtell

face picon face
Alan B. Pearce wrote:
>> The easiest way is to stay off the bleeding edge,
>> and wait for the mext revison to come out.
>>    
>
> Doesn't always work out that way for a couple of reasons ...
>
> 1. Microchip seem to reuse the VHDL for individual modules between all
> processors in a family, but the support teams for individual chips don't
> seem to talk to each other. See the recent thread where )IIRC) Bob Blick was
> having a problem with EEPROMs in a 12F series chip, and I pointed him at
> what sounded like a similar problem in 16F627/8 chips, but it wasn't noted
> as an errata for the 12F chips he was using.
>  
Actually, that was me (Bob Axtell). I finally alerted Microchip. They
wanted to know the datecode, which,
because I had shipped all 50 PIC12F629's used, I couldn't provide. But
one just popped up on the floor
of the lab a few days ago, and I can now provide that. Indeed, your
suggestion solved the problem for
me.
> 2. There is no way of knowing when Microchip change the silicon revision
> until you actually purchase chips and check the revision. So you could wait
> forever without knowing if they even fixed the bug ...
>
>  
They need to have a formal announcement of silicon revisions, and WHY it
was revised, to keep us from
being driven nuts.

--Bob

2006\12\11@081001 by Alan B. Pearce

face picon face
>Actually, that was me (Bob Axtell).

Sorry Bob, I couldn't remember precisely which of the several we have here
it was, and picked the wrong one. ;)

>They need to have a formal announcement of silicon revisions,
>and WHY it was revised, to keep us from being driven nuts.

I seem to recall Jinx having a similar problem, where he was needing to
insist on having a certain date code or later, and the local distributor
said they could handle that sort of order, but as you say, one needs to know
the info to start with ...

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