Compiler -O2 or -Os creates bad code for system/ulp/ulp_riscv/i2c example (IDFGH-11033)

[aircable]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

master 5.2.2

Operating System used.

Linux

How did you build your project?

Command line with idf.py

If you are using Windows, please specify command line type.

None

Development Kit.

ESP32S3-PICO-1

Power Supply used.

External 3.3V

What is the expected behavior?

I2C example uses the RTC I2C hardware to communicate with chips.
That works when compiled with option debug or -O0. With performance optimization -O2 or even size optimization -Os it can no longer communicate.

What is the actual behavior?

Initializing RTC I2C ...
E (298) ulp_riscv_i2c: Write Failed!
E (298) ulp_riscv_i2c: RTC I2C Interrupt Raw Reg 0x154
E (302) ulp_riscv_i2c: RTC I2C Status Reg 0x35ff0009
ERROR: Cannot communicate with I2C sensor

Steps to reproduce.

standard example examples/system/ulp/ulp_riscv/i2c
unmodified

Debug Logs.

No response

More Information.

No response

[aircable]

To make sure: this is on the XTENSA core, main processor on an ESP32-S3-PICO-1 chip, not on the ULP,
using the RTC I2C hardware.

In addition, reading and writing multiple bytes at once does not work either.
ulp_riscv_i2c_master_write_to_device( data, data_len );
Error message:
E (2354) ulp_riscv_i2c: Write Failed! E (2354) ulp_riscv_i2c: RTC I2C Interrupt Raw Reg 0x10c E (2354) ulp_riscv_i2c: RTC I2C Status Reg 0x66120001
Workaround: for loop and writing single bytes by also incrementing the slave_reg_addr.

[ESP-Marius]

@aircable Thanks for reporting this. I'll test on my side and follow up on this one.

[ESP-Marius]

I think I have a patch that should fix your problem with compiling on non OG optimizations (at least it worked for me locally):

0001-fix-ulp-i2c-fixed-ulp-i2c-not-working-from-main-cpu-.zip

Would be great if you could try the patch and check if it works for you as well!

In addition, reading and writing multiple bytes at once does not work either.

Was this issue related to optimization as well or more a generic issue? I was unable to reproduce this one.

[aircable]

Hi Marius, thanks for looking into this. I can confirm that the fix works now. I have tested with -O2 (performance) and communication with the I2C chip is working.

The multiple read/write has a problem independently of the GCC optimization. It never worked.
The first byte read (or write) works, but he second one fails with those errors,
Tested again:

I (1367) I2CULP: write: 0xe, reg: 0x1b, WRITE: 0xde, SIZE: 2
E (1881) ulp_riscv_i2c: Read Failed!
E (1881) ulp_riscv_i2c: RTC I2C Interrupt Raw Reg 0x10c
E (1881) ulp_riscv_i2c: RTC I2C Status Reg 0x65080000

Code to reproduce:

    ulp_riscv_i2c_master_set_slave_addr( handle.slave_address );
#if 0
    for( int i = 0; i < data_len; i++ ){
        ulp_riscv_i2c_master_set_slave_reg_addr( mem_address + i );
        ulp_riscv_i2c_master_read_from_device( &data[i], 1 );
        ESP_LOGI( TAG, "multi: 0x%x, reg: 0x%x, READ: 0x%x", handle.slave_address, mem_address + i, data[i] );
    }
#else    
    // FAILS
    ulp_riscv_i2c_master_set_slave_reg_addr( mem_address );
    ulp_riscv_i2c_master_read_from_device( data, data_len );
    ESP_LOGI( TAG, "multi: 0x%x, reg: 0x%x, READ: 0x%x", handle.slave_address, mem_address, data[0] );
#endif

BTW, any chance the RMT hardware has the same compiler optimization problem? I'm still trying to track that one down. I use this for the serial LED strips.

[ESP-Marius]

Hi Marius, thanks for looking into this. I can confirm that the fix works now. I have tested with -O2 (performance) and communication with the I2C chip is working.

Good to hear, I've submitted an internal MR to fix this problem and close this issue.

The first byte read (or write) works, but he second one fails with those errors

To better track this as a separate bug/issue I've split this into #12235
So far I'm unable to reproduce the problem, but we'll keep following up on it.

BTW, any chance the RMT hardware has the same compiler optimization problem? I'm still trying to track that one down. I use this for the serial LED strips.

Possibly, but hard to tell without more info. Would be great if you could open a new issue for this one as well, with some more description, and we can find someone responsible for RMT to take a look at it.