NI2C fails after long runtime and works again after power cycle

martinmoe · May 28th 2020

Hello,

we have at least 2 efusA9 Boards with the WEC 2013 V1.80 Firmware which experienced problems with the I²C (NI2C) after a long (probably several weeks) runtime.

Boards with V2.30 and newer have not yet shown such behavior. We are using I2C_B with no IRQ but write and read (with repeated start condition).

There are several Issues concerning NI2C (FSiMX6 Changelog.txt):

- 0003298: [NI2C] Setting values of drive strength and pull up doesn't work - resolved

- 0003294: [NI2C] Bus toggle doesn't work correctly if it is lock up - resolved

- 0003074: [NI2C] Repeated start does not work - resolved

- 0003040: [NI2C] Sometimes occurs an exception while boot process - resolved

- 0002935: [NI2C] efusA9: I2C_B_IRQ is configured as output - resolved

My question is: Are these issues addressing problems which may occur after a long runtime?

Here is a snippet how we use the driver:

Code

NI2C_MSG_HEADER txrxRequest[2] = {
{ (addr << 1) , 0x00, writeCount },
{ (addr << 1) | 1, 0x00, readCount }
};
result = DeviceIoControl(m_hI2CDevice, IOCTL_NI2C_TRANSFER, reinterpret_cast<LPVOID>(&txrxRequest[0]), sizeof(txrxRequest), pWriteReadBuffer, writeCount + readCount, NULL, NULL);
...

Kind Regards

Martin

fs-support_ZU · May 29th 2020

Hello,

i would not address this issues direct to your problem. E.g. when you not explicite use/set repeated start/drive strength so it should have no effect. Nevertheless i woould test and update to the latest kernel.

Which problems do you have on I2C in detail?

martinmoe · May 29th 2020

The problem is that the aforementioned DeviceIoControl returns failure after some runtime (with many transfers prior to failing). I cannot provide the exact value or if the function is ok again in the next call. It occurred in an end user application and I have only the information that the communication failed while communicating with at least 2 different devices (of different kind) on the bus.

I would like to know if the named issues fix any problems that may occur after some runtime or if the issues just fix things that would fail immediately. Or in other words: I want to know if the problem may be solved if we update to the latest kernel and drivers. Because if you didn't fix anything which is a problem after some runtime, the fixes are not relevant for us. (Updating the kernel in the field cannot be done).

Of course there could also be some electrical problem in the attached hardware, but when the device is powered off and on again, the problem is gone, which makes software suspicious.

Does the NI2C allocate memory in any form to do a transfer? If yes, then the "small memory leak" issue may also have an influence and the problem may be solved by using V2.20 or higher (issue 0003112).

I want to avoid an kernel update as long as I am not entirely sure the Update fixes the problem.

fs-support_ZU · May 29th 2020

Hello,

as already mention i would not address this resolved issues direct to your problem. And i see no possibility to fix this error without reproduce it in your office! I would prepare HW/SW so that i can measure line states/get further debug output. If you prepare cutable lines you may see if a slave helt the line(s) down in case of error.

>> Does the NI2C allocate memory in any form to do a Transfer?

<< No, but a Memory leak can be everywhere. Call "GlobalMemoryStatus" from time to time to check this

>> Updating the kernel in the field cannot be done

<< You can update kernel from OS: Update SW

But frist i would locate the probelem and test the solution.

NI2C fails after long runtime and works again after power cycle

Share

Tags