Bug with KL17? I2C Master producing glitches on SCL.

garrisonyogi · ‎03-07-2018

Bug Details

We're using a MKL17Z64VLH4 microcontroller as a I2C master to communicate with a PMBus device. When left running, the microcontroller occasionally produces glitched clock edges as can be seen below.

The glitch can be seen here in place of the 3^rd SCL pulse of the transmission. By counting the rest of the pulses, we can assume that when the master transmits this glitch, it believes that it is sending a full well-formed clock pulse. Data that we’ve collected shows that this glitch can occur in place of any of the clock pulses in the address transmission.

Is it possible that these glitches could be the result of misconfiguration of the I2C peripheral? Or has anyone seen similar glitches occurring? These glitches pose a fairly serious problem for us as some of them cause the I2C slaves to get confused and to hold the bus indefinitely (this can be seen at the end of the screenshot).

Configuration

We’re making use of the HAL library in order to interface with the I2C peripheral.

The peripheral is configured with the following calls to:

// Enable main clock to I2C peripheral

SIM_HAL_EnableClock(SIM, kSimClockGateI2c1);

// Configure pins to run in I2C mode

PORT_HAL_SetMuxMode(I2C_SDA, kPortMuxAlt2);

PORT_HAL_SetMuxMode(I2C_SCL, kPortMuxAlt2);

I2C_HAL_Init(I2C1);

// set baud rate to 100kHz

I2C_HAL_SetBaudRate(I2C1, i2cClockFreq, kI2cBaudRate, NULL);

I2C_HAL_Enable(I2C1);

Any help with this issue would be greatly appreciated!

mjbcswitzerland · ‎03-09-2018

Hi Giorgos

The double-buffered I2C in the KL17 has a number of errata that need to be considered - see the latest errata document for latest details.

Also see appendix A of the uTasker I2C user's document which points out a few rules to respect to ensure reliability: http://www.utasker.com/docs/uTasker/uTasker_I2C.pdf

The uTasker I2C driver has been used in various industrial products using intensive I2C operation for a couple of years without any issues but you may find it necessary to modify the NXP examples to achieve reliability. I believe that NXP also advises using DMA operation to work around some time critical problems, although this was not found to be essential.

Regards

Mark

Build with: CW10.x, KDS, MCUXpresso, IAR, Keil, Greenhills, Crossworks, CooCox, Atollic, S32 Design Studio, GNU Make and Visual Studio

I2C - http://www.utasker.com/docs/uTasker/uTasker_I2C.pdf

Free Open Source solution: https://github.com/uTasker/uTasker-Kinetis

Working project in 15 minutes video: https://youtu.be/K8ScSgpgQ6M

For better, faster, cheaper product developments consider the uTasker developer's version, professional Kinetis support, one-on-one training and complete fast-track project solutions to set you apart from the herd : http://www.utasker.com/support.html

garrisonyogi · ‎03-09-2018

Hi Mark,

Thank you for the information, do you happen to have a link to the latest KL17 errata document? The device datasheet mentions a document called xN89M (where x is the device revision), but all I can find is 1N89M which doesn't contain any relevant i2c errata!

Kind regards,

Giorgos

mjbcswitzerland · ‎03-09-2018

Hi Giorgos

Unfortunately there is a not a lot in the erratas as I see eg. https://www.nxp.com/docs/en/errata/KINETIS_L_1N71K.pdf
but there are many threads about problems:
eg.
https://community.nxp.com/message/460444
https://community.nxp.com/thread/377611

and I was communicating with someone from NXP a couple of years ago responsible for some updates. Although the migration guide was changed to include a few details it looks like that they are not considered as actual chip errata.

Quote:
The migration guide (AN4997) has indeed been updated to include double-buffered I2C requirements - Rev. 1 from 4/2016.

The change is:

First Revision:

5.9.1 Software impact

There is no software impact when using the updated I2C module.

Rev. 1:

5.9.1 Software impact

There is a significant software impact due to the double-buffering feature. Look at the double-buffering

mode section and the flowchart related to the I2C interrupt routine at the end of the I2C module section in

the corresponding MCU reference manual.

Consider these notes:

• Check the EMPTY status flag before writing to the I2C_D register and wait for the EMPTY flag

to write the second value to the I2C_D immediately after the first write (to apply the

double-buffering feature).

• The master must send the NACK before the repeat start in the buffering mode.

• The I2C module on the KLx6/KL34 MCUs must wait for the I2C_D register to be read to start the

next transaction. With the KL43/KL33/KL27/KL17 I2C module in the buffer mode, the TCF is

cleared automatically by the internal reading or writing into the I2C_D data register. You don’t

have to wait to read from/write to the I2C data register manually in the Rx/Tx mode.

• A delay is required during the repeated start sequence due to the EMPTY flag. Send the repeat start,

apply a small delay (depends on the I2C clock selection) before waiting for the EMPTY flag, and

then write to the I2C_D register.

I saw that some delays were built into the NXP drivers but without any explanation of what they were working around or whether they are needed. Delays in drivers tend to change timing slightly to maybe avoid a race state but also look to be random attempts to change some undesired behavior that may or may not work.

In fact I never saw I2C clock glitches so maybe you have something in your system that is changing the clock used by the I2C module for a short time that makes it do this (?)

Regards

Mark

garrisonyogi · ‎03-09-2018

Hi Mark,

Thanks again for all the detailed information! I'm afraid that I'm out of the office on Monday, but I'll review all of the information you've provided then and see if it's a fit for the problem we're seeing. As you say, there's still a suspicion that the problem that we're seeing is the result of some fault in our system, and not specifically in the microcontroller.

Cheers,

Giorgos

jingpan · ‎03-09-2018

Hi Giorgos,

Would you mind to post your circuit here? And please send me your clock setting, include system clock, cpu clock, and clock mode.

Regards,

Jing