• AVR Freaks

Helpful ReplyHot!MCP2221A Behaviour after NACK?

Senior Member
  • Total Posts : 50
  • Reward points : 0
  • Joined: 2014/10/23 06:59:16
  • Location: 0
  • Status: offline
2020/01/31 09:22:58 (permalink)

MCP2221A Behaviour after NACK?

I have a board using the MCP2221A USB-I2C Interface.
The I2C Interface is connected to a Newhaven NHD-0216CW-AB3 Character OLED Display Module
Ocasionally the display will NACK a command or address byte sent to it from the MCP2221
Once this happens all further HID Commands to the MCP2221 get the results code 0x01 I2C Engine is busy (command not completed).
After that all further attempts to communicate with the display do not get translated into I2C commands. 
I have used a logic analyzer, and an oscilloscope to look at the SCL and SDA lines and can see no reason for the NACK. Everything seems to be withing the required parameters. 
The first attached image shows the logic analyser showing a NACK to a WRIITE command:
The second attached image shows the Oscilloscope cpature of the same thing.
So first of all, any idea what could be causing the NACK?
And, more importantly, whats the correct way to handle the NACK in terms of HID commands to the MCP2221A - the only thing I can see is to reset the chip! That causes a USB re-enumeration and bing-bong sounds that annoy the user! Is there anothe way to reset the I2C engine?

Attached Image(s)

New Member
  • Total Posts : 2
  • Reward points : 0
  • Joined: 2020/02/06 21:41:16
  • Location: 0
  • Status: offline
Re: MCP2221A Behaviour after NACK? 2020/02/11 20:51:12 (permalink) ☄ Helpfulby SpiderKenny 2020/02/25 02:46:23
5 (1)
I can't speak to the reason or cause of the NACK, but I too often encounter it. You don't have to reset the entire device though, as you can simply reset the I2C state machine to a ready state, which will then let you send new I2C START conditions to read/write again. 
When you receive the NACK, send via USB HID the "STATUS/SET PARAMETERS" command (0x10) with the "Cancel current I2C/SMBus transfer" sub-command (also 0x10) at byte index 2. So the entire 64-byte command to send would simply be { 0x10, 0x00, 0x10, 0x00, 0x00 ... }. See page 23 in the datasheet:
When this value is put in this field, the device will cancel the
current I2C/SMBus transfer and will attempt to free the I2C bus.
This command is very useful since it can cancel a transfer and
free the bus. An example would be when trying to communicate
with a device using a wrong address. This will cause a timeout
to occur. This time-out situation can be read using the
“Status/Set Parameter” and the cancellation of the I2C/SMBus
transfer can be achieved by this sub-command.

Note that if you receive (yet another) 0x10 at byte 2 in the response message, you should wait "a few hundred microseconds" before attempting another I2C operation, per page 24 in the datasheet:
The current I2C/SMBus transfer was marked for
cancellation. The actual I2C/SMBus transfer cancellation
and bus release will need some time (a few hundreds of
microseconds, depending on the communication speed
initially chosen for the canceled transfer)

Been using this same technique successfully for a few days now!
Senior Member
  • Total Posts : 50
  • Reward points : 0
  • Joined: 2014/10/23 06:59:16
  • Location: 0
  • Status: offline
Re: MCP2221A Behaviour after NACK? 2020/02/25 02:48:26 (permalink)
4 (1)
Thanks Andrew!
I did eventually find out the cause of the NACKs -  the Newhaven OLED display can only work at 2.8V in I2C mode, 3.3V and 5V are not supported in that mode. The datasheet was a bit vauge on that detail!
I reduced to 2.8V and all is working well now - no more NACKs :-)
Jump to:
© 2020 APG vNext Commercial Version 4.5