I2C Read and Write Errors in v1.73 but not v1.71

[GJG]

I was successfully able to read data from a FT6336 touchscreen IC using a Raspberry Pi 3 Model B v1.2 (2015) running Raspbian GNU/Linux 11 (bullseye) with bcm2835 library 1.71. When I upgrade to version 1.73 of the library, I suddenly start getting BCM2835_I2C_REASON_ERROR_TIMEOUT and BCM2835_I2C_REASON_ERROR_DATA errors. Note, I did not change the firmware or hardware. All I did was install version 1.73 of the library, recompile my code with no changes, then run it and errors pop up almost every I2C read and write. When I reinstall version 1.71, everything works as expected, again with no changes to the code.

I'm checking for errors like:

    uint8_t reason = bcm2835_i2c_write(&addr, sizeof(addr));
    if (reason != BCM2835_I2C_REASON_OK)
    {
        printf("Writing to FT6336 address %x failed with reason (%x)\n", addr, reason);
    }
    reason = bcm2835_i2c_read(&data, sizeof(data));
    if (reason != BCM2835_I2C_REASON_OK)
    {
        printf("Reading from FT6336 address %x failed with reason (%x)\n", addr, reason);
    }

The most common error is BCM2835_I2C_REASON_ERROR_TIMEOUT, however, calling bcm2835_i2c_read after a timeout error still fills the variable "data" with correct information from the FT6336 IC. Only BCM2835_I2C_REASON_ERROR_DATA causes the "data" variable to be incorrect. Why would this change between version 1.71 and 1.73? From reading the revision history, it seems like timeout checks were added to 1.73 but why would that cause BCM2835_I2C_REASON_ERROR_DATA  in 1.73 but not 1.71?

Attached to this is minimal viable code to demonstrate the issue. Can you spot any problems even if you don't have FT6336 hardware?

[Simon Peacock]

Hi GJG

The timeout error was added to prevent a infinite loop issue if units didn't respond in time (or at all).  I suspect there is a significant delay in the touch screen causing this issue.

Have a look in bcm2835_i2c_write() for the failsafe variable.  Currently this is set to 1000 * len which should have been enough.  It might be that since you are looking for only 1 byte, the timeout isn't working (there may need to be a minimum value).  Also, if  you have a logic analyzer, check the I2C bus for stretching.

Simon

--
You received this message because you are subscribed to the Google Groups "bcm2835" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bcm2835+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bcm2835/69192eda-4837-4484-8c3b-7a57fe9fe7e0n%40googlegroups.com.

[GJG]

Thank you for the response Simon.

1. What unit is "1000 * len" in? If its microseconds, then that would explain the frequency of the timeout error. If its in milliseconds, im almost certain the reads take under a second.

2. The data read after a timeout is still valid. Is there anyway to change the time out length at runtime?

3. V1.71 never returns an i2c data error. What changed between the library versions with regard to that error? The same code will actually produce faulty i2c reads in 1.73 but not 1.71. Do you know why?

You received this message because you are subscribed to a topic in the Google Groups "bcm2835" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bcm2835/45O8Y_5yv00/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bcm2835+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bcm2835/CACXsFr1qrw_w5npiVxox6JULBkkLTHZie5Dm4z5zsPrtMjbVmQ%40mail.gmail.com.

[Simon Peacock]

The timeout is in CPU loops... It is a failsafe, so it depends on the data size (len * 1000).

ANd maybe it didn't return an error, BUT I had the Pi lock up on numerous occasions accessing a 4-line LCD display due to the unit occasionally not finishing the send.  The code was originally an infinite loop on hardware failure.  This occasionally happens on I2C due to rise time / levels / clocks etc..it may be a simple interface .. but failure is always an option.

Have a look at line 1318 in BCM2835.c, make it bigger and print what count value is left when an answer is found.  I did this under Raspberrian so there is a chance some of it got optimized.

Simon

To view this discussion on the web visit https://groups.google.com/d/msgid/bcm2835/CA%2Bqqht4Th689pt%3DjwpOTTjEZAvK1WmAHjAkDX1v-eLZWfLWAuQ%40mail.gmail.com.

[GJG]

I changed the failsafe on line 1318 of 

bcm2835.c to "unsigned long Failsafe = 10 * len * 1000;" I also added a debugging line on 1362.

printf("Remaining Failsafe: %d\n", (10 * len * 1000) - Failsafe);

Remaining CPU cycles left in the failsafe after this modification is ~300-1500. I don't see anymore data errors with this change.

In my application code, I was writing to a address then reading the response. I think the timeout was stopping the transmission mid write and causing the data errors.

Would the maintainer(s) be open to a function that allows the I2C timeout to be changed at runtime?

To view this discussion on the web visit https://groups.google.com/d/msgid/bcm2835/CACXsFr1z3L%2BW_jkkdwvhob%2BdOnd3HLnNhBOgMFF3H7D0XTQ8qg%40mail.gmail.com.

[Mike McCauley]

Hello,

On Tuesday, 7 November 2023 02:51:21 AEST GJG wrote:
> I changed the failsafe on line 1318 of
> bcm2835.c to "unsigned long Failsafe = 10 * len * 1000;" I also added a
> debugging line on 1362.
>
> printf("Remaining Failsafe: %d\n", (10 * len * 1000) - Failsafe);
>
> Remaining CPU cycles left in the failsafe after this modification is
> ~300-1500. I don't see anymore data errors with this change.
>
> In my application code, I was writing to a address then reading the
> response. I think the timeout was stopping the transmission mid write and
> causing the data errors.
>
> Would the maintainer(s) be open to a function that allows the I2C timeout
> to be changed at runtime?

Yes, provided it is tested and documented.

Cheers.

> >>>> <http://www.airspayce.com/mikem/bcm2835/group__constants.html#ggab59cd4
> >>>> 06976a819cff4505e978b27fcda46a451d6defc1119176f865305b0d8a3>>>>>
> >>>> and BCM2835_I2C_REASON_ERROR_DATA
> >>>>
> >>>> <http://www.airspayce.com/mikem/bcm2835/group__constants.html#ggab59cd4
> >>>> 06976a819cff4505e978b27fcda9941bd8c8b79c99d2da1fb93bfdb9524> errors.

> >>>> Note, I did not change the firmware or hardware. All I did was install
> >>>> version 1.73 of the library, recompile my code with no changes, then
> >>>> run it and errors pop up almost every I2C read and write. When I
> >>>> reinstall version 1.71, everything works as expected, again with no
> >>>> changes to the code.>>>>
> >>>> I'm checking for errors like:
> >>>> uint8_t reason = bcm2835_i2c_write(&addr, sizeof(addr));
> >>>> if (reason != BCM2835_I2C_REASON_OK)
> >>>> {
> >>>>
> >>>> printf("Writing to FT6336 address %x failed with reason
> >>>>
> >>>> (%x)\n", addr, reason);
> >>>>
> >>>> }
> >>>> reason = bcm2835_i2c_read(&data, sizeof(data));
> >>>> if (reason != BCM2835_I2C_REASON_OK)
> >>>> {
> >>>>
> >>>> printf("Reading from FT6336 address %x failed with reason
> >>>>
> >>>> (%x)\n", addr, reason);
> >>>>
> >>>> }
> >>>>
> >>>> The most common error is BCM2835_I2C_REASON_ERROR_TIMEOUT

> >>>> <http://www.airspayce.com/mikem/bcm2835/group__constants.html#ggab59cd4
> >>>> 06976a819cff4505e978b27fcda46a451d6defc1119176f865305b0d8a3>, however,

> >>>> calling bcm2835_i2c_read after a timeout error still fills the
> >>>> variable "data" with correct information from the FT6336 IC. Only
> >>>> BCM2835_I2C_REASON_ERROR_DATA

> >>>> <http://www.airspayce.com/mikem/bcm2835/group__constants.html#ggab59cd4
> >>>> 06976a819cff4505e978b27fcda9941bd8c8b79c99d2da1fb93bfdb9524> causes the

> >>>> "data" variable to be incorrect. Why would this change between version
> >>>> 1.71 and 1.73? From reading the revision history, it seems like
> >>>> timeout checks were added to 1.73 but why would that cause
> >>>> BCM2835_I2C_REASON_ERROR_DATA

> >>>> <http://www.airspayce.com/mikem/bcm2835/group__constants.html#ggab59cd4
> >>>> 06976a819cff4505e978b27fcda9941bd8c8b79c99d2da1fb93bfdb9524> in 1.73

> >>>> but not 1.71?
> >>>>
> >>>> Attached to this is minimal viable code to demonstrate the issue. Can
> >>>> you spot any problems even if you don't have FT6336 hardware?
> >>>>
> >>>> --
> >>>> You received this message because you are subscribed to the Google
> >>>> Groups "bcm2835" group.
> >>>> To unsubscribe from this group and stop receiving emails from it, send
> >>>> an email to bcm2835+u...@googlegroups.com.
> >>>> To view this discussion on the web visit
> >>>> https://groups.google.com/d/msgid/bcm2835/69192eda-4837-4484-8c3b-7a57f
> >>>> e9fe7e0n%40googlegroups.com

> >>>> <https://groups.google.com/d/msgid/bcm2835/69192eda-4837-4484-8c3b-7a5
> >>>> 7fe9fe7e0n%40googlegroups.com?utm_medium=email&utm_source=footer> .

> >>>
> >>> --
> >>> You received this message because you are subscribed to a topic in the
> >>> Google Groups "bcm2835" group.
> >>> To unsubscribe from this topic, visit
> >>> https://groups.google.com/d/topic/bcm2835/45O8Y_5yv00/unsubscribe.
> >>> To unsubscribe from this group and all its topics, send an email to
> >>> bcm2835+u...@googlegroups.com.
> >>> To view this discussion on the web visit
> >>> https://groups.google.com/d/msgid/bcm2835/CACXsFr1qrw_w5npiVxox6JULBkkLT
> >>> HZie5Dm4z5zsPrtMjbVmQ%40mail.gmail.com

> >>> <https://groups.google.com/d/msgid/bcm2835/CACXsFr1qrw_w5npiVxox6JULBkk
> >>> LTHZie5Dm4z5zsPrtMjbVmQ%40mail.gmail.com?utm_medium=email&utm_source=foo
> >>> ter> .

> >>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "bcm2835" group.
> >> To unsubscribe from this group and stop receiving emails from it, send an
> >> email to bcm2835+u...@googlegroups.com.
> >> To view this discussion on the web visit

> >> https://groups.google.com/d/msgid/bcm2835/CA%2Bqqht4Th689pt%3DjwpOTTjEZAv
> >> K1WmAHjAkDX1v-eLZWfLWAuQ%40mail.gmail.com
> >> <https://groups.google.com/d/msgid/bcm2835/CA%2Bqqht4Th689pt%3DjwpOTTjEZ
> >> AvK1WmAHjAkDX1v-eLZWfLWAuQ%40mail.gmail.com?utm_medium=email&utm_source=f
> >> ooter> .

> >
> > --
> > You received this message because you are subscribed to a topic in the
> > Google Groups "bcm2835" group.
> > To unsubscribe from this topic, visit
> > https://groups.google.com/d/topic/bcm2835/45O8Y_5yv00/unsubscribe.
> > To unsubscribe from this group and all its topics, send an email to
> > bcm2835+u...@googlegroups.com.
> > To view this discussion on the web visit

> > https://groups.google.com/d/msgid/bcm2835/CACXsFr1z3L%2BW_jkkdwvhob%2BdOnd
> > 3HLnNhBOgMFF3H7D0XTQ8qg%40mail.gmail.com
> > <https://groups.google.com/d/msgid/bcm2835/CACXsFr1z3L%2BW_jkkdwvhob%2BdO
> > nd3HLnNhBOgMFF3H7D0XTQ8qg%40mail.gmail.com?utm_medium=email&utm_source=foo
> > ter> .


--
Mike McCauley VK4AMM mi...@airspayce.com
Airspayce Pty Ltd 9 Bulbul Place Currumbin Waters QLD 4223 Australia
http://www.airspayce.com 5R3MRFM2+X6
Phone +61 7 5598-7474

[Sean ONeill]

Hi

Thanks for developing the library.

I have two display libraries(An LCD and OLED)  built using bcm2835  library for I2C access.

Both of them began displaying intermittent BCM2835_I2C_REASON_ERROR_TIMEOUT  errors on upgrade to V1.73 from V1.71

However the errors are only present when I2C clock  speed  is set to  BCM2835_I2C_CLOCK_DIVIDER_2500 .

At clock speed BCM2835_I2C_CLOCK_DIVIDER_626    The display's work perfect with zero errors.

I have no problem running them at higher speed just reporting what I observed.

Regards

[Mike McCauley]

Thanks Sean,
we cant understand why that would be.

Do you say the problemis present in V1.73 but not V1.71?

Cheers.

On Tuesday, 30 January 2024 05:41:24 AEST Sean ONeill wrote:
> Hi
>
> Thanks for developing the library.
>
> I have two display libraries(An LCD and OLED) built using bcm2835 library
> for I2C access.
> Both of them began displaying intermittent BCM2835_I2C_REASON_ERROR_TIMEOUT

> <http://www.airspayce.com/mikem/bcm2835/group__constants.html#ggab59cd406976
> a819cff4505e978b27fcda46a451d6defc1119176f865305b0d8a3> errors on upgrade to

a

[Sean ONeill]

Hi

Yes.

I even uninstalled 1.73 and reinstalled 1.71 and ran my test routine programs again on both display libraries.

Then reinstalled 1.73 again and replicated problem.

I know which bcm2835 version is running because my test routine program prints it out at start.

1.71 No errors  at any I2C clock speed.

1.73 Intermittent BCM2835_I2C_REASON_ERROR_TIMEOUT errors at  clock speed BCM2835_I2C_CLOCK_DIVIDER_2500

1.73 No errors at clock speed BCM2835_I2C_CLOCK_DIVIDER_626

• Raspberry PI 3 model b
• C++, g++ (Debian 12.2.0)
• Raspbian , Debian 12 bookworm OS, , 64 bit.
• kernel : aarch64 Linux 6.1.0-rpi7-rpi-v8

regards

[Mike McCauley]

Thanks again,

we have now uploaded new version 1.74 that increases the timeout for
bcm2835_i2c_write().

Please let me know if this fixes the issue.

Cheers.

On Tuesday, 30 January 2024 05:41:24 AEST Sean ONeill wrote:

> Hi
>
> Thanks for developing the library.
>
> I have two display libraries(An LCD and OLED) built using bcm2835 library
> for I2C access.
> Both of them began displaying intermittent BCM2835_I2C_REASON_ERROR_TIMEOUT

> <http://www.airspayce.com/mikem/bcm2835/group__constants.html#ggab59cd406976
> a819cff4505e978b27fcda46a451d6defc1119176f865305b0d8a3> errors on upgrade to

[Sean ONeill]

Hi

I have downloaded Version 1.74 and ran my test routines at different speeds against both my I2C display libraries

Zero  BCM2835_I2C_REASON_ERROR_TIMEOUT where recorded. Problem appears fixed.

There is one small issue , the link on your home page http://www.airspayce.com/mikem/bcm2835/ 

is still pointing to version 1.73 .

I had to copy the link address and change 3 to 4 to  get the download.

Thanks again.

[Mike McCauley]

Thanks and link has been fixed