IDF5.3 ESP32s3, NAU88C22, delay between SDA and SCL

[liekla]

Dear community,

I am unable to communicate with the NAU88C22 audio codec using I2C on the ESP32s3 under IDF 5.3. Here is the setup: I have a custom-designed PCB with an I2C bus. The ESP32s3 is configured as the I2C master, and there are several I2C slaves on the bus, including an AHT20, an LSM6DS3, an NAU88C22 codec, and an STM32G431. The STM32G431 usually operates as an I2C slave.

Communication with the AHT20, LSM6DS3, and STM32G431 works without any issues using the ESP32s3. However, I am unable to reach the NAU88C22 codec.

However, when I reconfigure the STM32G431 to act as an I2C master and disable the ESP32s3, the NAU88C22 codec is accessible. To further diagnose the issue, I captured the communication with my oscilloscope. I noticed that the SDA line consistently lags behind the SCL line by about 1 microsecond. In contrast, with the STM32G431 as the master, the SCL and SDA lines are perfectly synchronized.

Could this be the cause of the communication issues? How can it be resolved?

This is my very simple test code for the ESP32

Code: Select all

#include <driver/i2c_master.h>
#define TAG "MAIN"
#include "esp_log.h"

void app_main(void)
{
    i2c_master_bus_handle_t bus_handle;
    i2c_master_bus_config_t i2c_mst_config = {
        .i2c_port = 0,
        .sda_io_num = 4,
        .scl_io_num = 5,
        .clk_source = I2C_CLK_SRC_DEFAULT,
        .glitch_ignore_cnt = 7,
        .intr_priority = 3,
        .trans_queue_depth = 0,
        .flags = {
            .enable_internal_pullup = 1,
        }};
    i2c_new_master_bus(&i2c_mst_config, &bus_handle);
    while(true){
        i2c_master_probe(bus_handle, 0x1A, 100);
    }

    for (uint8_t i = 1; i < 128; i++)
    {
        if (i2c_master_probe(bus_handle, i, 100) != ESP_ERR_NOT_FOUND)
        {
            ESP_LOGI(TAG, "Found I2C-Device @ 0x%02X", i);
        }
    }
}

Attachment: oscilloscope hardcopy, top=SDA, bottom=SCL, measument= delay of SDA with respect to SCL, ca. 1us

Regards, Klaus

[Sprite]

Could be your glitch_ignore_cnt setting; iirc the ESP32 reads SCK to see if it indeed changed before it moves on, and glitch filtering may delay that.

Note that this actually is valid I2C: according to the specs, SDA can change whenever SCL is low, so this shouldn't cause the NAU88C22 to not be recognized. (Additionally, a project of mine is driving a closely-related NAY88c10 with the same glitch filtering settings and it works perfectly fine.)

[liekla]

I changed the glitch_count to 0 and to 1, but this does neither affect the waveform nor the accessibility of NAU88C22.

Hmm, well, yes: According to the spec, the behaviour of the ESP32s3 is perfectly fine. But this lag is the only visible difference between the (working) STM32 and the (non-working) ESP32 waveform.

Its frustrating...

What am I missing? Has anybody any further advice?

[Sprite]

Agree that this is weird. Thinking outside of the box: are there any other lines influenced by one of the two MCUs that can influence how the codec works? E.g. CSB/GPIO1 or MODE?

[liekla]

Thank you, ESP_Sprite for brainstorming for me!

[*]CSB/GPIO1 is NC
[*]MODE is pulled down with a 10k resistor

For further checks, I uploaded the schematics and a 3D rendering to get a first impression of the board. All project files are available here https://github.com/klaus-liebler/labathome. The "deep link" to the KiCad project is https://github.com/klaus-liebler/labath ... home_pcb15

[Sprite]

Hm, that all looks perfectly good to me. One thought I had is that maybe the chip needs MCLK to function, but I don't think that's the case: the datasheet doesn't mention it and my own code for the NAU88C10 initializes I2C before it initializes I2S and that works well. I'm honestly scratching my head here. Do you have a 2nd PCB you can test this on? Maybe something freakish is going on, like e.g. the 3v3 of the codec not being connected so it draws parasitic power from the other IO or something?

[MicroController]

Just for fun, let's see what happens if you call i2c_master_bus_reset() just after i2c_new_master_bus().

[liekla]

One thought I had is that maybe the chip needs MCLK to function, but I don't think that's the case: the datasheet doesn't mention it and my own code for the NAU88C10 initializes I2C before it initializes I2S and that works well.

Well, in my tests with the STM32, the ESP32 is executing a _NOP-Waiting-Loop without doing anything (except the things, that happen before app_main()). Hence, there is no I2S-Interface and especially no MCLK active.

Do you have a 2nd PCB you can test this on?

Yes, I have 5 PCBs and I tested 3 of them.

Maybe something freakish is going on...

For sure! <ironic mode on> I suspect the ESP32 senses that its fiercest rival in the microcontroller world is sitting 5cm next to it on the same PCB. It is therefore offended and makes this known with nasty errors.</ironic mode off>

3v3 of the codec not being connected so it draws parasitic power from the other IO or something?

I double checked with my multimeter and the finest test tips, whether all 3.3V pins get the proper voltage. Well they do..

Just for fun, let's see what happens if you call i2c_master_bus_reset() just after i2c_new_master_bus().

A Guru Meditation Error happens...

Code: Select all

I (304) gpio: GPIO[4]| InputEn: 1| OutputEn: 1| OpenDrain: 1| Pullup: 1| Pulldown: 0| Intr:0
I (314) gpio: GPIO[5]| InputEn: 1| OutputEn: 1| OpenDrain: 1| Pullup: 1| Pulldown: 0| Intr:0 
Guru Meditation Error: Core  0 panic'ed (LoadProhibited). Exception was unhandled.

Core  0 register dump:
PC      : 0x42019008  PS      : 0x00060330  A0      : 0x8200c8ad  A1      : 0x3fc984f0
0x42019008: i2c_ll_get_scl_clk_timing at C:/Users/mail/esp/v5.3/esp-idf/components/hal/esp32s3/include/hal/i2c_ll.h:980
 (inlined by) i2c_hal_get_timing_config at C:/Users/mail/esp/v5.3/esp-idf/components/hal/i2c_hal.c:71

A2      : 0x3fc99948  A3      : 0x3fc98520  A4      : 0x00000000  A5      : 0x00060523
A6      : 0x00000001  A7      : 0x3fc99cf4  A8      : 0x00000000  A9      : 0x3fc984f0
A10     : 0x00060523  A11     : 0x00000000  A12     : 0x00060520  A13     : 0x3fc99dd0
A14     : 0x3fc99d4c  A15     : 0x00000000  SAR     : 0x00000018  EXCCAUSE: 0x0000001c
EXCVADDR: 0x00000038  LBEG    : 0x400570e8  LEND    : 0x400570f3  LCOUNT  : 0x00000000
0x400570e8: memset in ROM
0x400570f3: memset in ROM



Backtrace: 0x42019005:0x3fc984f0 0x4200c8aa:0x3fc98520 0x4200d0ac:0x3fc98580 0x42008ccf:0x3fc985b0 0x4201a1db:0x3fc98600 0x4037a929:0x3fc98630  
0x42019005: i2c_ll_get_scl_clk_timing at C:/Users/mail/esp/v5.3/esp-idf/components/hal/esp32s3/include/hal/i2c_ll.h:980
 (inlined by) i2c_hal_get_timing_config at C:/Users/mail/esp/v5.3/esp-idf/components/hal/i2c_hal.c:71
0x4200c8aa: s_i2c_hw_fsm_reset at C:/Users/mail/esp/v5.3/esp-idf/components/esp_driver_i2c/i2c_master.c:96
0x4200d0ac: i2c_master_bus_reset at C:/Users/mail/esp/v5.3/esp-idf/components/esp_driver_i2c/i2c_master.c:1054
0x42008ccf: app_main at C:/repos/playground/espidf-i2c_scanner/main/hello_world_main.c:28
0x4201a1db: main_task at C:/Users/mail/esp/v5.3/esp-idf/components/freertos/app_startup.c:208
0x4037a929: vPortTaskWrapper at C:/Users/mail/esp/v5.3/esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:134

With the call commeted out, everything* works (*except, the missing 0x1A NAU88C22)

Code: Select all

I (305) main_task: Calling app_main()
I (305) gpio: GPIO[4]| InputEn: 1| OutputEn: 1| OpenDrain: 1| Pullup: 1| Pulldown: 0| Intr:0
I (315) gpio: GPIO[5]| InputEn: 1| OutputEn: 1| OpenDrain: 1| Pullup: 1| Pulldown: 0| Intr:0
I (335) MAIN: Found I2C-Device @ 0x38
I (335) MAIN: Found I2C-Device @ 0x6A
I (345) main_task: Returned from app_main()

For your reference, scanner code is

Code: Select all

#include <driver/i2c_master.h>
#define TAG "MAIN"
#include "esp_log.h"
#include "sdkconfig.h"
#include "freertos/FreeRTOS.h"
#include "freertos/task.h"

void app_main(void)
{
    i2c_master_bus_handle_t bus_handle;
    i2c_master_bus_config_t i2c_mst_config = {
        .i2c_port = 0,
        .sda_io_num = 4,
        .scl_io_num = 5,
        .clk_source = I2C_CLK_SRC_DEFAULT,
        .glitch_ignore_cnt = 0,
        .intr_priority = 3,
        .trans_queue_depth = 0,
        .flags = {
            .enable_internal_pullup = 1,
        }};
    i2c_new_master_bus(&i2c_mst_config, &bus_handle);
    //i2c_master_bus_reset(&bus_handle);
    
    for (uint8_t i = 1; i < 128; i++)
    {
        if (i2c_master_probe(bus_handle, i, 100) != ESP_ERR_NOT_FOUND)
        {
            ESP_LOGI(TAG, "Found I2C-Device @ 0x%02X", i);
        }
    }
}

[boarchuz]

I'm not sure exactly which field controls the delay but if you mess with these one-by-one and view the result with your oscilloscope, you'll find it eventually: https://github.com/espressif/esp-idf/bl ... /i2c_reg.h

Some likely candidates: I2C_SCL_LOW_PERIOD, I2C_SDA_HOLD_TIME, I2C_SDA_SAMPLE_TIME, I2C_SCL_HIGH_PERIOD, I2C_SCL_WAIT_HIGH_PERIOD

[MicroController]

Code: Select all

i2c_master_bus_reset(&bus_handle);

should actually be

Code: Select all

i2c_master_bus_reset( bus_handle );