> Brian, I want to retrieve the eratta for the 16C74, 16C74 and 16C65. > > which files should I look for at the WWW ?????? They're under tech support. Since the files take awhile to download via modem if you don't have a direct net connection, I'll summarize (this summary is not complete, but indicates the ones I remember). First, though, an editorial.... Some people, here and elsewhere, have sharply criticized Microchip for releasing chips with "so many" bugs. Despite my like for the PIC, I am inclined, depressedly, to agree with them that many of the high-end PICs' peripherals are rendered largely useless by these bugs. HOWEVER, despite the problems in the high-end chips I STILL intend to support MicroChip to the extent I can. Despite the failings of the PICs in the more "upscale" applications, the lower models such as the 16C5x or 16C62x are IMHO some of the best "little" micros there are: cheap, fast, and great to program. Further, the PIC family is the ONLY family of micros I know of where someone can buy an under-$10 micro from Digi-Key, $10 or so in stuff from Radio Shack, and grab some free info off the web, and have an in-circuit development system. In addition, despite their shortcomings, Microchip has been reasonably forward about their chips' problems. Perhaps this was their long-standing intent; perhaps they're merely trying to avoid a "Pentium" fiasco. I personally don't really care which--I just want them to survive and keep producing great little micros [though a 28-pin EEPROM part would be nice]... In closing, I would just like to offer my moral support to the folks at Microchip who are probably sweating nervously as to how the market will react to their "buggy" chips. It is only through their hard work and effort that such wonderful chips as the 16C84 are available, and I hope in future even more wonderful things will spring forth. If there is anything I can do to help anyone at Microchip in their efforts to produce better (hopefully bug-free) chips I would be happy to do what I can, and I invite anyone at Microchip to write me personally (if needed, I'll sign a reasonable non-disclosure agreement). -- John Anyway, here's what I remember offhand of the errata I've looked at. This is not an exhaustive list, and my description of II is unlike any in the errata but I think it describes the actual mechanics of the related prob- lems. So here goes... I. Serial Hardware Bugs [A] UARTs will not receive reliably if BRGH is set for high baud rates. [B] SPI mode has clocking problems [C] I2C mode has problems in master mode [for I2C mastering, it's often easier to ignore the I2C hardware]. [D] Suspected problem [not listed in errata, nor tested]: Writing a byte to the outgoing serial buffer will clear any incoming byte that happens to be there. [If this is not the case, it would see M'chip added some logic to the CPU core to prevent read-before-write on MOVWF.] II. CPU Core Limitation/Quirk [A] On 16Cxx, all instructions other than xxxLW will perform a read of the address specified in the lower seven address bits. [On the 16C5x, the lower 5 bits, but no registers are affected by reads so this is a non-issue]. - On all 16Cxx except the 5x parts, this affects MOVWF (does a read before write), and depending upon where FSR is pointing, may also affect NOP and the canonical form of CLRW (with an address of 0). If one is courageous, one might be able to specify an address in CLRW to simultaneously perform the read and clear W; this is most likely not useful. - On the 16C64, 16C74, and other parts with a parallel slave-port, the LSB's of the RETURN instruction will cause the port to be read, potentially causing a host CPU store there to be misregistered. A possible workaround would be to use a different opcode for RETURN, but I don't know if the hardware would accept any others. III. Power/crosstalk problems [A] Some PICs will not power-up reliably without an externally-imposed reset [/MClr]. [B] Some PICs will not reliably assert the PO flag on power-up and this flag should not be used for power-on detection. [C] On the 16C71, the CPU oscillator can cause crosstalk with the ADC input right next to it. In addition, use of an external RC main oscillator may cause the internal RC for the ADC to fail if it is used. Both of these problems may be somewhat mitigated by using the CPU clock as the ADC source. [D] On parts with an "external" crystal oscillator option (e.g. to use a watch crystal for a timebase and something else for the main CPU clock) this oscillator may pick of crosstalk from the main oscillator if both are used simultaneously, and use of this other oscillator may cause increased power draw as its digital input function is not dis- abled by use as an oscillator. [E] Some chips will behave badly in case of brownout and will have to be power-cycled to recover. IV. Other miscellaneous [A] On the 16C74, the ADC may be inaccurate for measuring voltages over 3 volts. [B] On some parts with extra timers, these timers will malfunction in certain modes (see errata for more details). [C] On the PIC16C84, it is possible to unblow the security fuse and read out the chip contents. This is not believed possible on the other chips. [D] On many of the newer ceramic chips, there is no way to unblow the security fuse--even UV erasure won't help. This is mentioned in the data sheets, but should be repeated. V. Documentation notes: [A] The pinouts for the 28-pin surface mount parts are documented in- correctly. See Errata for correct pinouts. [B] On the 16C62x, the PORTB inputs operate as "normal" PIC inputs; only the PORTA inputs operate as schmidt triggers. [C] For some devices, the exact AC/DC tested parameters don't match the data sheets.