Microchip datasheet rant MCP9600

[wreeve]

Can it be true Microchip…..really….is the datasheet for the MCP9600 really incorrect…..YES IT BLOODY WELL IS…
SCL and SDA are transposed on the pin-out
Fcking unbelievable…..they manage to get it right on their dev. board….I have buzzed it out…and the dev. board schematic pdf is correct…..and when the bodge wires are added to my prototype PCB all is well.
I am not angry the error crept in the datasheet. I am furious they didn’t fix it instantly… I will not be the first to have spotted it; costs a few hundred quid on prototypes and a couple of hours of my time!

[JPortici]

i don't know what's going on lately. every part which was released since august-september 2015 has rather incorrect or incomplete ("preliminary") datasheets that hasn't beed fixed/completed yet. you might very well be one of the first users

[RogerRowland]

Assuming this is the datasheet you mean, http://ww1.microchip.com/downloads/en/DeviceDoc/20005426A.pdf

The diagram on page 1 says SCL is pin 20 and SDA is pin 19, while the table on page 13 says SCL is pin 19 and SDA is pin 20.

For the record, which is right?

[wreeve]

SCL is on 19, SDA is 20.

One of my first "debug" routines is to look on here for the part number to see if anyone else has encountered it!

It's a great piece of silicon to be honest; allows me to cram a K type interface in a fraction of the space I used 10 years ago! You get to the stage where you doubt yourself, your oscilloscope and your eyes.....how can that datasheet get through to print and more importantly why wasn't it corrected!

I have dropped an email to Microchip!

[Ian.M]

Typical of Microchip.   While their documentation is usually well presented and easy to use you just cant trust its accuracy, mostly due to idiot mistakes and copy/paste errors.  Usually there is enough info available to resolve the discrepancies without resorting to experimentation, but not always.  Their tardiness in publishing documentation errata and fixing the original documentation is also lamentable.

If there was ONE thing that I wish Microchip would introduce (apart from a working forum), it would be a public bugtracker tied to their support ticket system, + modifying the ticket system to let the user separate confidential information and files from those that can go on the bug tracker, with strong encouragement to make as much public as possible.

[wreeve]

No rush then! Still at least I got a reply!

 **** Proposed Resolution Begin ****
Hi William,

In the datasheet: http://ww1.microchip.com/downloads/en/DeviceDoc/20005426A.pdf
page 1 is wrong and page 13 is correct.

The issue is reported to be corrected in the next version of the document.
Sorry for the inconvenience.

Regards,
Nicu
 **** Proposed Resolution End ******

[tszaboo]

And that is one of the reason, why I reluctant to use Microchip parts.  A prototype costs several hundred for a company, so a screw up like this means it is never worth to use them money wise. Keeping my sanity is also very important. And dont get me started on niche microcontrollers from them!

[Pjotr]

Data sheets of PIC microcontollers were always half way and messy. Not only that, they also refuse to document bugs properly. We have had a long e-mail conversation 10 years ago with MC about a bug in one of their DSP Pics. First they denied the bug but finally a real technician popped in and confessed the bug. And explained the inns and outs. There were no plans to fix it and it was later on never documented.

[poorchava]

I agree with all of the above, but I still use their parts anyway. Their microcontrollers are generally shit, but they do offer cheap, simple and available chips that just get the job done. Voltage references, low voltage opamps, mosfet drivers, temperature sensors and a few other chips.

I have just learned to verify on a breadboard that the chip can actually do what they advertise before integrating their chip into way design.

Sent from my HTC One M8s using Tapatalk.

[Pjotr]

Indeed, their analogue parts are usually fine and cheap. But their mcu's are only good for mass market products to get your "stumble and fall" develop investments back.

[Buriedcode]

Not trying to start another 'these micro's are better than those', but my experience with microchip has generally been pretty good.  And their MCU's, like all MCU's, fit into certain niches.  For super simple 'MCU and battery + passives' type project, they can be extremely low power, have all the peripherals one could need, and often less than a dollar.  For one-offs I still just 'use a small PIC' to to relatively mundane tasks like sensor conditioning, a 'smart ADC', display drivers etc..  because they reduce board space and BOM.  These are areas that even a cortex-M0 would be overkill, and AVR's too expensive and power hungry.

Whilst I haven't done a mass production in a while, I still find myself looking at the 8/14-pin devices for something that requires a 'bit of intelligence'.  In portable applications such as remote controls they can be very cost effective.

I'll admit I too have spotted errors in datasheets, actually quite a few that really did look like copy-paste errors from other devices.  The PIC24FJ128GB202 datasheet had lots of stuff copied over from the PIC32 that weren't' even relevant to the device.  And there's a number of dubious 'DC specs' in the PIC16F1704 datasheet.  Then again, I'm sure we all do prototypes before a beta design to catch these things.