ESP32-S2 vs ESP32 inconsistent SPI results [IDFGH-3390]

[aleix.rokubun]

Hello all,

I just received my first ESP32-S2 boards and started porting a small example that was working on a "regular" ESP32, and things were going surprisingly good until SPI got in the way.

I'm testing an UWB module from Decawave attached to the SPI2_HOST bus, on both boards. On the regular ESP32 the result of reading register 0 (chip ID) is 0x30 0x01 0xCA 0xDE, however the ESP32-S2 returns 0x60 0x03 0x95 0xBC

I checked with the logic analyzer and in fact what the UWB module is outputting is correct, but for some reason data gets mixed up on the chip.

I have the device configured to use DMA transfers this way:

Initialization function:

Code: Select all

DWM1000_t dwm_init(void) {

    DWM1000_t device;
    esp_err_t ret = ESP_OK;
    device.isError = 0;

    #ifdef USE_DWM_LOGS
    ESP_LOGI(TAG, "Initializing DWM1000 device.");
    #endif

    memset(&device.spi_config, 0x00, sizeof(device.spi_config));
    memset(&device.spi_handle, 0x00, sizeof(device.spi_handle));
    
    spi_bus_config_t buscfg={

        .miso_io_num = PIN_SPI_MISO,
        .mosi_io_num = PIN_SPI_MOSI,
        .sclk_io_num = PIN_SPI_CLK,
        .quadwp_io_num = -1,
        .quadhd_io_num = -1,
        .max_transfer_sz = SPI_MAX_DMA_LEN,
    };

    spi_device_interface_config_t devcfg={

        .input_delay_ns = 100,
        .command_bits = 0,
        .address_bits = 0,
        .dummy_bits = 0,
        .duty_cycle_pos = 0,
        .cs_ena_pretrans = 5,
        .cs_ena_posttrans = 5,
        .clock_speed_hz = SPI_CLK_FREQ,
        .mode = SPI_MODE,
        .spics_io_num = PIN_SPI_CS,
        .queue_size = 1,
        .flags = 0,
        .pre_cb = NULL,
        .post_cb = NULL,
    };

    ret = spi_bus_initialize(SPI_CHANNEL, &buscfg, SPI_DMA_CHANNEL);
    ESP_ERROR_CHECK(ret);

    device.spi_config.cs_io = PIN_SPI_CS;
    device.spi_config.host = SPI_CHANNEL;
    device.spi_config.miso_io = PIN_SPI_MISO;

    ret = spi_init(&device.spi_config, &device.spi_handle, &devcfg);
    ESP_ERROR_CHECK(ret);

    #ifdef USE_DWM_LOGS
    ESP_LOGI(TAG, "DWM1000 initialization done success.");
    #endif

    return (device);
}

Write/read function:

Code: Select all

esp_err_t spi_dma_transfer_bytes(spi_context_t* ctx, uint8_t cmd, uint8_t *txBuffer, uint8_t *rxBuffer, uint16_t length) {
    
    esp_err_t err;

    err = spi_device_acquire_bus(ctx->spi, portMAX_DELAY);
    if (err != ESP_OK) return err;


    uint8_t* buf = (uint8_t*)malloc(sizeof(uint8_t)*length + 1);
    if (buf == NULL) return ESP_ERR_NO_MEM;

    memset(buf, 0x00,length*sizeof(uint8_t) + 1);
    memmove(&buf[1], txBuffer, length*sizeof(uint8_t));

    buf[0] = cmd;
    
    spi_transaction_t trans_t;

    trans_t.rx_buffer = rxBuffer;
    trans_t.tx_buffer = buf;

    trans_t.length = (8 * length) + 8;
    trans_t.rxlength = trans_t.length;
    trans_t.flags = 0;
    trans_t.cmd = 0;
    trans_t.addr = 0;
    trans_t.user = NULL;

    err = spi_device_transmit(ctx->spi, &trans_t);

    memmove(rxBuffer, &rxBuffer[1], length*sizeof(uint8_t));
    rxBuffer[length] = 0x00;

    spi_device_release_bus(ctx->spi);
    free (buf);

    return err;
}

So far I've tried tweaking speeds and delays with no effect whatsoever, is it possible there's a flag or setting missing in my configuration causing this odd behavior?

Thanks,

[ESP_michael]

Hi aleix,

Seen from your data on ESP32 and ESP32-S2, it looks very like there is one bit shift in the bitstream when reading by ESP32-S2. This may be the mismatch between the SPI mode of DM1000 and ESP32-S2. When the SPI mode of ESP32-S2 is incorrectly set, it will fetch the data just during the transition of MISO from DM1000, cause some issues.

Seen from the spec of DM1000, it uses GPIO 5 and 6 to select the SPI modes, which are all internally pulled down. If no external connections, the SPI mode should be 0. But could you check again whether there are other stuff on the GPIO 5 and 6 that make it high during startup? Measurement of those pins after startup is also useful.

You can try to change the SPI mode of ESP32-S2 among 0-3 according to the value of GPIO5 and 6 to match the mode of DM1000.

Note:
1. To make this bug easier to debug, suggest use slow clock, no larger than 10MHz (I suggest 1MHz). This will prevent all timing issues except from the SPI mode
2. If you still have problem after trying all mode 0-3, please attach a oscilloscope capture which contains 8 SPI clock cycles, the CS active edge, and configuration of ESP32-S2 SPI Master device.

Thanks,
Michael

[ESP_Alvin]

Moderator's note: edit the topic title for issue tracking, thanks.

[aleix.rokubun]

Hi Michael,

Sorry for the delay, I thought an email to a new response on this thread would be sent to me. Anyway, yes, you're right, data is shifted one bit to the right.

I confirm GPIOs 5 and 6 of the module only had an external 10K pull-down each that I added in an act of pure desperation , anyway I have one board with the pull-downs and one without and no difference is appreciated.

As suggested I tried setting different SPI modes (strapping pins on module + on the code), and the issue still persists.

There's something quite strange here, the bit-shift is only present when the SPI clock is below ~16MHz, otherwise data appears to be read properly (however some part of the module initialization fails due to excessive SPI clock before clock initialization).
Regardless of the speed, both the logic analyzer and the oscilloscope properly decode MISO data. Find attached a composite screenshot of a transfer using mode 0.

Thanks a lot!

[ESP_michael]

Hi Aleix,

I found two more possible issues:

1. The `input_delay_ns` in your device config is 100ns, but that value seems to be 12ns according to its spec. Could you please try setting that value to 0, 10, 12(recomendded), 20 and see what happen?

2. According to the LA waveform, the slave seems to be working in mode 1. Could you either check the actual level of GPIO5 and 6 at startup, or try to configure the device into mode 1?

Michael.

[aleix.rokubun]

Hi Michael,

Regarding the input delay it was one of the multiple combinations tested to see if I appreciated any difference on the input results, it must have slipped into the code snippet posted on my initial post.

This week I had to attend other matters, but as suggested I tried the following with no difference at all:

- Changed input delay from 0 to 100ns [0, 10, 12, 20, 40, 50, 100] with the following increments as suggested
- Removed external SPI mode setting resistors (leaving the default SPI mode 0)
- Changed SPI mode from 0 to 3 using external resistors
- Changed the SPI bus pins to other GPIOs
- Tried running the SPI transactions as polling transactions

I don't really know what else to do, the part is operating properly on an ESP32, running the same code, but we do want to start transitioning to the S2 to have the HW and code ready for WiFi ToF

Any other suggestions on how to address this issue?

[ESP_michael]

Hi aleix,

Another idea, could you try increase `cs_ena_pretrans` and `cs_ena_posttrans` to about 10. See: https://docs.espressif.com/projects/esp ... _pretransE.

Also, I'm not sure if your slave actually applied different SPI modes as you expect. Seen from the waveform you posted above, when you connect both GPIO 5 and 6 to ground, the slave is still working in mode 1 instead of the expected mode 0.

[albercook]

Any progress on the ToF hardware?

When I search all I see is that it is not supported yet. Any information on where the specifications for the ToF hardware can be found.

Specifically looking to measure ToF between two esp32-s2 devices which should be a lot simpler than than arbitrary access point.

[MiFirst]

Hi aleix,

do you have any progress with your problem? Could you please share the complete code of your implementation with us.

Best regards,
Mifirst