It is currently 15 Dec 2018 07:35

All times are UTC + 1 hour




Post new topic Reply to topic  [ 11 posts ] 
Author Message
PostPosted: 30 May 2014 22:45 
Offline

Joined: 28 Aug 2013 18:28
Posts: 179
I am using the hardware I2C library to control an EEPROM and RTC.

Occasionally the program gets stuck in the I2C routine to read from the EEPROM (or the RTC registers). It just hangs. A restart of the program does not help. The only option is to remove power from the EEPROM or RTC (essentially from the I2C device's VDD pin). This clears the hang up and a restart of the program then runs fine.

I have noted this same problem on other programs I have written with my own I2C routines in the microchip MPLAB environment. It is a hardware issue with the I2C device itself. Since these devices do not have a CS or reset function, they are not easy to get to reset from s/w when the internal flow is waiting for something on the I2C protocol.

There are some articles on the internet about ways to try to provide a s/w reset sequence. I implemented one such method in the past, but given that I was writing my own I2C driver, this could be done - it went something like issuing a STOP followed by a number of writes of 1's and then a RESTART.

I note that the mE Software I2C library has a Soft_I2C_Break() function. It seems to be to address such "hanging" in the internal cycle of I2C chips. The mE Hardware I2C library does not seem to have a similar function. Given that I am not using the software I2C library, how can I implement this same functionality.

Thanks


Top
 Profile  
 
PostPosted: 13 Jun 2014 09:07 
Offline
mikroElektronika team
User avatar

Joined: 25 Jan 2008 09:56
Posts: 10117
Hi,

Please, have a look at the following topic :
viewtopic.php?f=178&t=54794

Regards,
Filip.


Top
 Profile  
 
PostPosted: 17 Jun 2014 13:55 
Offline

Joined: 29 Jul 2009 09:48
Posts: 664
Location: Sheffield
If you have to power cycle the I2C devices, aren't these causing the problem?

What devices are they and are you using the correct I2C bus pull-ups (you may need to alter the pull-up resistances if you have multiple devices on the same bus)?

I have used a number of I2C ADC, RGB Sensors, Temp sensors, EEPROMS and RTC chips and the only problems I have had have been my doing when I forgot to put a track to one of the pull up resistors.

If your devices have a reset, you could take advantage of this.
Drive the reset for each device from a spare port pin and at the start of your code, issue a reset to each device for the required time (in the data sheet).
Therefore a Watchdog reset could be used to check for a timeout and a full hardware reset would result when the watchdog timed out.

voila, no more power cycling required but fixing the lock-up must be a priority as it is not normal.

Regards,
Dave


Top
 Profile  
 
PostPosted: 25 Jun 2014 20:26 
Offline

Joined: 28 Aug 2013 18:28
Posts: 179
As I tried to explain - it is a hardware issue with the I2C device itself.

These devices do not have a CS or reset function. If they get into a situation where their internal cycle does not complete, they can not send an ACK or NACK.

I suggest Filip read the question again and also the postings he has linked to. In these we are pointing out that I2C devices can get into a "hung" state where they cease to communicate as required. The way the I2C driver in mE is written, it will sit waiting for a response and hang the system, since there is no timeout set with the mE library when waiting for ACK or NACK from the device (which is unable to send this).

The only option is to power cycle the I2C device to clear this.

So my question again to Filip - the mE Software I2C library has a Soft_I2C_Break() function. This seems to be intended to address such "hanging" in the internal cycle of I2C chips. The mE Hardware I2C library does not seem to have a similar function. How is the user meant to implement this same functionality to handle a hung I2C slave device?


Top
 Profile  
 
PostPosted: 25 Jun 2014 23:27 
Offline

Joined: 24 Nov 2005 20:07
Posts: 1171
Location: Colorado, USA
The better answer is to write your own hardware I2C functions that include a timeout exception routine and not always rely on mE to provide the solution.
What is odd is I two have designed countless commercial products using various I2C devices and never had a "hang" problem like you have described.

That said, most I2C devices are low power enough whereby you can dedicate an I/O port as a switchable VDD source (pullups tied to it as well) eliminating this "hang" problem all together. Since the common I2C VDD is now under firmware control it can be toggled when the hang condition occurs.


Top
 Profile  
 
PostPosted: 26 Jun 2014 02:34 
Offline

Joined: 24 Nov 2012 07:05
Posts: 183
Location: Thailand
Hi all,

This issue is prabably solved easily but i just wonder that why ME's Team don't do it.
In the bus system having many devices were connected and master read data from them ,
it is not make sense if a mulfuntion device don't return ACK bit then I2C library lock up so that this bus is dead because of just only one device.

It is easy to return status bit of i2c device by reading data at 9th clock as standard then return this bit.
this way allow master identify which device perform mulfunction because it don't return Ack bit and consider to replace it to fix it easily.

ps. sorry for my english

best regards.
prakob
.


Top
 Profile  
 
PostPosted: 26 Jun 2014 19:21 
Offline

Joined: 28 Aug 2013 18:28
Posts: 179
Thanks to you both for the suggestions. I like the idea of providing VDD to the I2C RTC device via a port pin. This way one can cycle power to the peripheral if the need arises.

Also, I could try reading after the 9th clk but I guess this would involve switching the SDA line to a regular i/p pin using TRIS, if I understood the suggestion correctly.

To the point that I2C devices do not "hang", I can assure you I have seen it a few times in totally different projects I have worked on, with totally different I2C devices and drivers. Right now I am using an I2C RTC and I2C EEPROM. On less than 0.001% of the time, on initializing of these devices, this hanging happens. It can be the RTC or EEPROM where it happens too. If one of these devices does hang, there is nothing you can do to get it going. You can have the WDT reset the uP and restart the program which in turn run the initializing part of the code, but this will again jam at the point of trying to talk with the RTC or EEPROM (which ever caused the hang and WDT out). Only option is to remove power from the offending I2C device to get it up and running again. Using a pin port for this purpose is a good idea.

Note, there is some mention of this problem on the microchip forum, and some have suggested various s/w sequences like sending 9 x STOP frames to unscramble the I2C device from within s/w if a timeout occurs, but I have not found this to clear the jam in all cases.

My point to Filip is really to point out that the I2C s/w library has a Soft_I2C_Break() function while the h/w library does not. I assume this Soft_I2C_Break() function is intended to be called if you make a timeout wrapper for the I2C write and read functions. My interest is to know what the code behind the Soft_I2C_Break() function is, as this is probably the way to unscramble an I2C device that is in a locked up state (without cycling its power supply).


Top
 Profile  
 
PostPosted: 27 Jun 2014 16:15 
Offline
mikroElektronika team
User avatar

Joined: 25 Jan 2008 09:56
Posts: 10117
Hi,

Quote:
This issue is prabably solved easily but i just wonder that why ME's Team don't do it.
In the bus system having many devices were connected and master read data from them ,
it is not make sense if a mulfuntion device don't return ACK bit then I2C library lock up so that this bus is dead because of just only one device.

This is already passed to our developers.
Currently the I2C library is implemented according to I2C specifications, unfortunately I2C specification does not specify any timeout conditions - an I2C device can occupy the bus for an arbitrary time period.

Regards,
Filip.


Top
 Profile  
 
PostPosted: 29 Jul 2014 16:39 
Offline

Joined: 28 Aug 2013 18:28
Posts: 179
I partially see your point Filip - yes I2C specifications do not define a timeout response - but this may be evading the issue a bit.

It is good coding to not have some means of a timeout escape if a hardware device locks up and fails to respond with the expected ACK or NACK (via SDA line).

Your mE developers saw fit to have such a function in the soft I2C library, so why not also in the hardware I2C library? It would not seem hard to have a timeout wrapper around each I2C function call to address this possibility.

Thanks.


Top
 Profile  
 
PostPosted: 29 Jul 2014 19:47 
Offline

Joined: 18 Jun 2008 11:43
Posts: 3767
Location: Nieuwpoort, Belgium
Hi, perhaps see http://www.libstock.com/projects/view/1052/i2c-with-timeout:
Replacement routines for I2c1_Rd and I2c1_Wr but here with timeout, so no blocking any more when a device one tries to access is not present. The mE I2c library is still needed for the remaining I2c routines. For the moment only for P16 and P18 Pic's with only one HW I2c module.

Sould be translatable to mC easily.

Usage (e.g. in mP):
  ...
  I2c1_Wr_TimeOut(Data_, 250); // Write “Data_” with a timeout of 2500 microseconds (2.5 millisecs)
  If (I2cTimeOut > 0)       // Test if TimeOut
  then …                         // OK
  else …                         // timeout error (device does no respond in time)
  ...


One remark: if an I2c device holds low SCL or SDA then also these routines won't help...

_________________
Kind regards, Dany.
Forget your perfect offering. There is a crack in everything, that's how the light gets in... (L. Cohen)


Top
 Profile  
 
PostPosted: 05 Aug 2014 14:14 
Offline

Joined: 28 Aug 2013 18:28
Posts: 179
Hi Dany,

Many thanks for pointing me to your posting - I will look more closely at it.

Quote:
One remark: if an I2c device holds low SCL or SDA then also these routines won't help...

This seems to be the issue - that an I2C slave device can get disrupted in its internal timing cycle and not respond properly. Two issues then present themselves:

i) ensuring the master has some sort of timeout, so as not to just keep waiting for the slave to respond (and this is where your link helps), and
ii) the issue of how to "reset" the slave given that there is no reset line for these devices. Some articles describe sequences of sending stop and start bits to try to get it communicating again. I have tried this and it seems sometimes to work (depending on I2C chip). Other approach is to cycle the power to the slave - this certainly works and this is where the suggestion from an earlier post to power the chip from a port line of the MCU, is a good idea.

Thank you.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 11 posts ] 

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 6 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: