I2C Locks Up issue on Vybrid

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

I2C Locks Up issue on Vybrid

1,315 Views
kubiznak_petr
Contributor V

On Vybrid, I'm experiencing a lock-up problem, which seems to be related to the one described at Re: MQX 4.0 I2C Locks Up. Even though the thread MQX4.1.1: Is the I2C Locks Up bug fixed? says the issue is fixed for MQX 4.1.1, which I'm using, the problem is still on. Anyway, these threads discuss the Kinetis sources (i2c_pol_ki2c.c, i2c_int_ki2c.c), while Vybrid has their own (i2c_pol_qi2c.c, i2c_int_qi2c.c).

My code sometimes (randomly) locks in a while loop at line 374 of i2c_int_qi2c.c (function _qi2c_int_tx()):

io_info_ptr->STATISTICS.TX_PACKETS++;
while (0 == (i2c_ptr->I2SR & QI2C_I2SR_IBIF))
{_PSP_SYNC();};   /* wait for address transferred */

Using the polled drivers did not really help, locking e.g. at line 776 of i2c_pol_qi2c.c (function _qi2c_polled_rx_txl()):

        }
    } while (0 == (i2csr & QI2C_I2SR_IBIF));

So my question is - is there a fix of this issue for the Vybrid platform? If not, is there a safe way of recovering from the problem e.g. in a software watchdog task? I mean e.g. resetting the bus without causing any further problems...

Message was edited by: Petr Kubizňák There was an incorrect problematic line stated.

Tags (4)
0 Kudos
9 Replies

765 Views
alejandrolozan1
NXP Employee
NXP Employee

Hi,

Just as a simple workaround it is worth trying to use a time out. Maybe using a counter that breaks the loop when expires.

Best Regards,

Alejandro

0 Kudos

765 Views
kubiznak_petr
Contributor V

Hi Alejandro,

Thank you for your answer. You are right that such workaround should fix the problem. Anyway, I believe it is a task of Freescale to fix the issue in the MQX sources, not task of every individual MQX user to fix the problem in their installations.

MQX is pretty far from the state of ideal software product. But I understand that there are bugs in every software. I found a bug. I reported the bug here. I even provided links on related threads, showing that the (probably) same bug was already fixed for the Kinetis platform. I believe it is not my task to fix the code and then perhaps beg Freescale to accept my fix. So, can you please delegate the problem to the people responsible for this part of code, which would provide an official patch? I would really appreciate that.

Petr

0 Kudos

765 Views
alejandrolozan1
NXP Employee
NXP Employee

Sure,

I can report the problem. But to do so, I need to reproduce the problem before reporting the issue.

Is it possible to reproduce the issue with one of our boards?

/Alejandro

0 Kudos

765 Views
kubiznak_petr
Contributor V

alejandrolozano, did you please report the issue? Is the fix in progress?

Thank you, Petr

0 Kudos

765 Views
alejandrolozan1
NXP Employee
NXP Employee

Hi,

I understand, but I have to reproduce the problem before contact R&D to modify this.

Anyway I will find out a way to do it.

Best Regards,

Alejandro

0 Kudos

765 Views
kubiznak_petr
Contributor V

Hi Alejandro,

I don't have any functional Freescale board with Vybrid. Also, as the issue is of random occurrence, there is no straight-forward way to reproduce on well-designed board. Anyway, it should not be a problem to cause the communication unreliable by replacing the resistors by a non-ideal value.

On the other hand, I don't think it is really needed to reproduce the issue. The issue itself is that there are infinite while loops in the driver. Compare i2c_int_qi2c.c with i2c_int_ki2c.c. You can find that the latter one does not contain any loop, while the prior one does. That's what needs to be fixed.

0 Kudos

765 Views
kef2
Senior Contributor IV

Try checking with scope. If you get I2C SCK prematurely cancelled like in the thread below, then I guess there's no SW workaround for problem. Hard reset would make I2C working again, but it is little not practical... Perhaps try lowering pull up resistance on SCL to make rising edge steeper, it could help. Or like I did for single slave app, try making SCL pin push-pull instead of open drain. Should work even with many slaves if you lower SCK freq. to the level, at which clock stretching doesn't happen. You need to have current limiting resistor on SCK pin, just in case some slave decides to pull SCK low while Vybrid drives it high.

Re: VIU3 to I2C SCL interference?

765 Views
kubiznak_petr
Contributor V

Hi Edward,

Thank you for these tips. Proper hardware configuration is of course the main aspect of working communication. On the other hand, I disagree that there is no SW solution to unreliable communication. For example, alejandrolozano already proposed one, even though not applicable for MQX users.

Anyway, my point is that even though we already played with the HW configuration, the communication still remains unreliable. And even if we manage to find a setting which would never show any defects, it still does not mean there is not any defect. Hence, since every communication is in principle unreliable, it is a task of software to handle any potential issues. MQX obviously does not do that in case of Vybrid, but the thread MQX4.1.1: Is the I2C Locks Up bug fixed? shows that the (possibly) same issue has already been fixed for Kinetis. So my question was targeted mainly on the Freescale support, so they can confirm this is the same issue and offer some solution inside MQX.

0 Kudos

765 Views
kubiznak_petr
Contributor V

(Just moved the question from the MQX category, as obviously no-one cares there...)

0 Kudos