I2C_Write blocking waiting for ACK

[csturner]

Hello,

I have scoured the forums looking for a solution to this, but I haven't found any. I am using the STM32 dev board (STM32F407) and I am running in to 2 issues with the I2C Library:
1) If the slave device isn't present and the controller doesn't receive an ACK, the I2C_Read and I2C_Write functions cause the devices to "freeze" (i.e. they are blocking).
2) If the controller is reset mid-message with the slave device, there is no way to reset the bus.

Does anyone have a solution to this?

MikroElektronika - are there any plans to update the I2C library to address this? If not, can I get the source from the library so that I can modify it to address these issues?

Regards,
Cam

[dejan.odabasic]

Hello,

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.

Additional obscure I2C problems are listed on this web page:
http://www.i2c-bus.org/obscure-problems/

Please understand that source code of compiler built-in libraries is not public due to the company's policy.
Thank you for understanding.

Best regards.

[csturner]

While what you say is certainly true, it isn't very useful for the entire application to lock up when trying to read from a device that isn't present.

It would be much more beneficial if you either:
1) Added a timeout (say 1 second), where if there is no acknowledgement from the slave on the address byte, or any byte for that matter, the read / write functions exit with an error code and allow the application to keep running.
2) Implemented SM bus

As written, your libraries are very dangerous to use. Not all slave devices comply exactly to the spec, and if any failure occurs, the board requires a reset.

Thanks for your response.

[dejan.odabasic]

Hello,

Compiler I2C library is designed to be used with devices which are compatible with I2C bus specification.
Timeout modification that you suggested deviates from the standard, but I have presented your suggestion to our developers and they will consider it.

SM but implementation would require much more customization since there are few major differences when SM bus is compared with I2C bus.
(electrical, timing, protocols and operating modes).

Best regards.

[prakob]

Hi Dejan,

I agree with csturner because there are many suggestion in embedded programming to using loop timeouts to avoid hanging of microcontroller while waiting for hardware operation.

For Examples,

Code: Select all

while (!ADCON1bits.DONE);	// 3. wait for the conversion to complete ###

Such code is potential unreliable, because there are circumstances under which microcontroller may hang if ADC has been incorrectly initialized, we can not sure that ADC's conversion will complete.

About I2C bus specification, I think that the program should not wait for acknowledge bit in while loop.
The application program should not hang in while loop just because of no receiver is present or damaged receiver.




The I2C function should return either Acknowledge (ACK) or Not Acknowledge (NACK) bit instead of hanging and let user to make decision what is the meaning of return bit as the recommendation from attached picture.

Cradit: I2C-bus specification and user manual, NXP

Best Regards

[panooli]

I have the same problem with the i2c functions for STM32F4xx, which are useless in the current version.

The problem is not only the missing time out, but also the version such as the registers are checked.
It lacks the review whether the hardware reports an error (e.g. "I2C_SR1.AF - Acknowledge failure" if addressed hardware is not exist).
Your comparison of I2Cx_Get_Status with a fixed values results in a endless loop if an error bit is set and a "normal" finish is not coming

As a suggestion for improvement:
1. immediate abort the function with return a error if a hardware-error-bit is set
2. an (configurable) time out as second failsafe for all other errors



PS: The I2C functions for Stellaris M3 does not have this problems

[ilferrari]

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.

I think this is a misunderstanding of what is quoted there. We are talking about what the receiver does on the ninth clock pulse - there is no need to wait or timeout. The master clocks out the ninth bit and the ACK gets logged in hardware and should be returned back to the user. It is impossible to do acknowledge polling, which is a normal write procedure with I2C eeproms.

I think the library design is wrong here - it should just return the ACK value and definitely not hang. I hope ME will take another look at this.

[Val Gretchev]

Without a time-division-multiplexing operating system, all tasks in your code should be written as state machines. That is also true for using I2C which can hang up the system if something goes wrong. Also, avoid using Delay_ms(); which stalls the processor for the duration of the delay.

I posted an article on LibStock you may be able to adapt for your needs. See:
http://libstock.mikroe.com/projects/vie ... tm32-board

Val Gretchev

[ITDesigns]

Hello,

Compiler I2C library is designed to be used with devices which are compatible with I2C bus specification.
Timeout modification that you suggested deviates from the standard, but I have presented your suggestion to our developers and they will consider it.

SM but implementation would require much more customization since there are few major differences when SM bus is compared with I2C bus.
(electrical, timing, protocols and operating modes).

Best regards.

OK Dejan
Its 3 years later - do we / will we have a timeout function for the I2C ?
This is not a question of whether it deviates from the I2C specification -
- Its a matter of simple practicality and good coding practice.
How can I report a problem if an I2C device has failed ?

Well I can't if it goes in to an infinite loop !!

Its great to see Val's solution but this really ought to be part of the library functions.
Thanks Val, I'll try and cobble something together in Pascal and post it

Regards

Geoff

[filip]

Hi,

Unfortunately, this is not yet implemented in the I2C library, so you should still use the solution given on this page.

Regards,
Filip.

[ITDesigns]

Hi,

Unfortunately, this is not yet implemented in the I2C library, so you should still use the solution given on this page.

Regards,
Filip.

Unfortunately, I am working in mikroPascal, so I can't use the solution given on this page. . . .

Regards

Geoff

[ITDesigns]

Hi

Why is
I2Cn_Start a function
I2C_Read a procedure
I2C_Write a function ?

[filip]

Hi,

I2Cn_Start returns 0 if I2C started OK and -1 if there is an error.
I2C_Read and Write both should be procedures, for some reason the Write is a function, but it only returns 0 in any case.

Thank you for spotting this, I will present this to our developer.s

Regards,
Filip.

[ITDesigns]

Hi
I have posted a solution to this problem for mikroPascal on libstock :-
1468287584_i2c_library_func_mikropascal_arm
I hope it is useful to anyone else who has had this problem.
I should be relatively easy to convert to mikroC

Geoff

[Synaps3]

Could someone please point me to the I2C code for mikroC for PIC that works around this problem?

I am starting to realize the laziness of the mikroC team. This has been an issue for years and instead they rely on users to submit code to fix problems with their own software. Add an optional timeout. It shouldn't be that hard.

And the whole thing about this not being part of the I2C standard - Timeout has nothing to do with the standard, it is a side issue that is fixed by good coding practice. That is not an excuse. How do you expect your software to be used in professional products when it goes into infinite loop on error?