Page 1 of 2

I2C on ESP32-WROOM-32 BUG

Posted: Sat Apr 16, 2022 9:42 pm
by unity-control
Hi all.

Found a bug with the I2C Master Component on ESP32, I wonder if you can help me please.

Simple program attached. Works fine in Software mode target slave address is 0x88 (note the time base on the scope is 5ms per divison = THIS IS WEIRD, it's way too slow)

Now same component also at 100KHz, only in I2C Hardware mode (Channel 1 or Channel 2 produce the same problem)

When I zoom into the signal, I see just rubbish data:

Thanks for your help!

Re: I2C on ESP32-WROOM-32 BUG

Posted: Sat Apr 16, 2022 9:44 pm
by unity-control
The 2 sample programs attached

Re: I2C on ESP32-WROOM-32 BUG

Posted: Mon Apr 18, 2022 10:24 am
by LeighM
With the hardware version, could you try adding an infinite loop, with a delay enclosed, at the end of the main

Re: I2C on ESP32-WROOM-32 BUG

Posted: Mon Apr 18, 2022 11:59 am
by mnfisher
One thing I noticed is that you have the i2c speed set to a non standard rate... Have you tried setting the i2c to 100k / 400k?

Martin

Re: I2C on ESP32-WROOM-32 BUG

Posted: Mon Apr 18, 2022 4:29 pm
by unity-control
Hi Martin,

Thanks for your lines. The speed is set back to 100KHz, I was trying different speeds to see if there would be any difference, but same issue.

I've also added a loop at the end and just tested the lst program on hardware, confirmed the same issue I'm afraid :-(

Cheers
R

Re: I2C on ESP32-WROOM-32 BUG

Posted: Mon Apr 18, 2022 7:47 pm
by mnfisher
Just tested this on a wroom board and the output of the address looks okay... If there is nothing attached to the i2c then the data isn't sent (no ACK is received)

I added a loop to repeatedly output to i2c
i2c test.fcfx
(10.03 KiB) Downloaded 78 times
LabNation_Screenshot4.png
LabNation_Screenshot4.png (238.58 KiB) Viewed 2842 times
Shows the address byte - I'm not expecting data (no ACK)...

There is however - definitely a bug in i2c_transaction_write (I'm sure this has been covered before?) - in that the length of the buffer is hard-coded as 20 bytes - so if an attempt is made to transmit more than 20 bytes it will fail..

Code: Select all

MX_UINT16 FCD_005f1_I2C__Transaction_Write(MX_UINT8 *FCL_BUFFER, MX_UINT16 FCLsz_BUFFER, MX_UINT16 FCL_LENGTH)
{
    //Local variable definitions
    MX_UINT16 FCR_RETVAL;


    // .Return = cal_i2c :: Transaction_Write(.Buffer, .Length)
    FCR_RETVAL = FC_CAL_I2C_Transaction_Write_1(FCL_BUFFER, 20, FCL_LENGTH);

    return (FCR_RETVAL);

}
20 - should be replaced by FCLsz_BUFFER.....

Martin

Re: I2C on ESP32-WROOM-32 BUG

Posted: Tue Apr 19, 2022 10:10 am
by unity-control
Hi Martin,

Thanks for your efforts. Have you tried the same GPIOs I've used? If I use software mode all works fine with the slave address 0x88 I am using.

R

Re: I2C on ESP32-WROOM-32 BUG

Posted: Tue Apr 19, 2022 10:17 am
by unity-control
"20 - should be replaced by FCLsz_BUFFER....."

I have checked the C code and this line is present in the C code output generated:
// .Return = cal_i2c :: Transaction_Write(.Buffer, .Length)
FCR_RETVAL = FC_CAL_I2C_Transaction_Write_1(FCL_BUFFER, 20, FCL_LENGTH);

How can I fix this moving forward or should I wait for a fix?

Regards!
R

Re: I2C on ESP32-WROOM-32 BUG

Posted: Tue Apr 19, 2022 12:11 pm
by mnfisher
I used the pins as per your example (A25/B0 from memory) - and address of 8 (also as per example). I don't think the esp32 allows 'any' pin to be used - check on the uart output (@115200) - errors will get displayed if you've used an invalid combination. it 'might' be possible via the config to alter this ??

Do you have something attached to the i2c bus? - as mentioned no data is sent if no ACK is received.

The 'issue' mentioned above only affects things if you send more than 20 bytes at once - it's possible to workaround by defining your own 'send' - though hopefully get a fix to the library fairly quickly...


Martin

Re: I2C on ESP32-WROOM-32 BUG

Posted: Tue Apr 19, 2022 12:53 pm
by unity-control
Thanks Martin,

I don't get any errors on the console... strange.

The scope capture is single shot of the first frames sent, so def. a bit weird that output...

I also have nothing else on the bus, I reckon the WROOM32 board has an issue, I have plenty of them, so will try another one and get back with the results.

Cheers!
R