Watch out for those pesky erratas

Got burned by the errata? Yup, we have a bunch of times. This also happened to Matseng on his 6502 Single Board Computer Emulator.

The datasheet (Atmel XMEGA D4) plainly said that the Port E can be used as a secondary I2C port, so with that assumption in mind he connected an I2C EEPROM to it. Only to find out, when he got his PCB, that it doesn’t work. A quick check in the errata marks this function as unavailable, without a fix.

Ah crap…. The art of not reading the erratas of the datasheets strikes back!

I’ve connected the I2C eeprom to PE0/PE1 on the ATXMEGA32 beause according to the datasheet that is the secondary TWI/I2C port. But after struggling two hours trying to get it work I took a look at the SDA/SLC lines as saw that they were completely dead.

Via the forum.


Join the Conversation


  1. To say the XMega is ‘quirky’ is to be diplomatic. I looked at it briefly when a commercial product I was designing got too big for an atmega… and the comments in the avr forums about it were essentially “stay away – use an ARM instead!” And they were right!

  2. By now I know to carefully read all available documentation, so the worst I’m affected is the letdown of finding that the seemingly perfect chip I found isn’t suitable after all. Of course there’s still the risk of previously unknown errata, but I’ve been lucky in that regard so far.

    It seems to me there’s more and more errata of the type “so-and-so peripheral is not functional”. Is due to changes in how MCUs are designed and tested? Since many chips launch with these types of documented errata they must have been caught in testing, but someone still made the decision to start selling them rather than respin the silicon.

  3. @arhi: Yes, I just adapted Peter Fleurys I2C lib to XMEGA. It works just fine, and is actually easier to use than the hardware implementation – and it got a rather small footprint as well. Happy, happy…

    And to the pendejos at the chip manufacturers that can’t be bothered to actually update the specs in the datasheets instead of just doing an errata I say – “*u** you” :-)

    1. On the other hand what TI does (at least for their Luminary parts), integrating the errata into the main datasheet and removing them from the errata sheet is infinitely worse, as suddenly your design checklist is just gone.

  4. When starting a design, and when buying parts, get the most current errata, and review the list, and make sure the errata matches the chip silicon rev number (assuming there is one).

    Trip up 1: Design with current errata, when chips are bought they are a different rev, with different errata including failed fixes, and new bugs.

    Trip up 2: Errata is for one rev of chip, and vendor/distributor supplies old stock with older version.

    Trip up 3: Idiots at chip vendor remove older errata items from errata document when a new version of the chip comes out, with no mention of chip rev number within the errata document, or its file name. Oblivious to designers using existing stock on hand of older rev chips, or doing firmware updates to systems in the field. In my case I have 200 boards with a QFN32 chip that needs to be reworked.

    Recommendation 1: Refuse to use products from vendors that don’t make access to errata as easy as access to the data sheet.

  5. There seems to be now way of reading the rev # from the firmware on a xmega. But there are a lot of other infos to get. Like wafer coordinates – probably a good tool for yield debugging for Atmel. themselves.

    “The Production Signature Row is a separate memory section for factory programmed data. It
    contains calibration data for functions such as oscillators and analog modules.
    The production signature row also contains a device ID that identify each microcontroller device
    type, and a serial number that is unique for each manufactured device. The device ID for the
    available XMEGA A1 devices is shown in Table 7-1 on page 14. The serial number consist of
    the production LOT number, wafer number, and wafer coordinates for the device”

    1. This would not be good. The content could change at any time, and having a fixed version that multiple people can refer to would require digging through the wiki history. To see what a disaster this could be, just look at the documentation for Altium, which is now a vast mish-mash of pages that can randomly point to varying versions of the software over the last 12 years.

  6. That depends on how you represent the data. For example if you use a section or column in a table to describe differences of revisions resulting in an always up to date and accurate datasheet. That altium has bad docs using a wiki (also how does a software manual compare to an ic datasheet) doesnt mean the idea is bad.

Leave a comment

Your email address will not be published. Required fields are marked *

Notify me of followup comments via e-mail. You can also subscribe without commenting.