Posted by: Claudio Carbone | 21 February 2012

I2C Followup – Microchip’s errata

I2C Display

I2C Display

After much much (much!!!) fiddling I finally have the I2C module working.

How did you solve the problems?

Nice question. Short version: I didn’t.
In fact I still have tickets open with microchip about the I2C modules on the 440F128H: I haven’t been able to get any of  them to work.
It could be fault in my code. True, but a fellow on the microchip forums volunteered to share his code.
It does not work at all.
It could be a hardware fault. True but I have multiple instances of the same board: some with the 440F128H and some with the 695F512H.
The 695 work without any problem, I even tested I2C ports 3 and 5 (and in the process discovered a nice errata that’s still uncorrected: every port from 3 through 5 MAY NOT correctly determine the bus status when the module is first powered on. In my case this means that port 5 needs an external physical cycling of the I2C pins, while port 3 works like a charm) and they work without a problem.

No chance of getting ANY port to work on the 440.
Well this means I’m not going to use that chip in any future project.

Anyway the errata on the PIC32 family looks awful to say the least.
After three revisions they did not correct any issue!
The I2C means you can’t use those ports as a master without resolving to spend a GPIO pin to cycle the I2C bus. If you’re the slave… well good luck: either you derogate to the bus rules and power cycle the lines, or you have to modify any other master’s code to do it for you. Or loose the first message every time you power up.
But go have a look at the SPI errata too, it’s simply incredible that after three revisions the most powerful chips of a manufacturer are still affected by such problems as

  • SPI Slave Mode. A wake-up interrupt may not be clearable.
  • DMA CRC Append Mode. In Pattern Match mode, the DMA module may not append all of the CRC results to the result buffer.
  • I2C™ . The SDA line state may not be detected correctly.
  • SPI. Byte writes to the SPISTAT register are not decoded correctly.

This is just a short list, I reported what to me seems something that deserved to be correct after 3 hardware iterations.
All the more because in 3 iterations the only thing that changed is the I2C problem reported above (corrected in the 3rd iteration).

Well I’m not a silicon engineer, but I can’t but remain puzzled by this.
Let’s see what comes out of the other problem with the I2C.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Categories

%d bloggers like this: