I2S: Bit-Alignment in 24bit Mono mode

RE: I2S: Bit-Alignment in 24bit Mono mode

Moritz_S — Thu, 28 Jul 2022 13:04:09 GMT

I found the answer to my problem. I used the queue in overflow mode, which caused the data distortion + I think NRF_LOG_INFO() and printf() should be avoided for debugging such issues. It seems they also do not output all the data. However, I also don't know another efficient way to debug this.

More details about this can be found here: devzone.nordicsemi.com/.../sending-i2s-data-via-ble-using-queue

RE: I2S: Bit-Alignment in 24bit Mono mode

Moritz_S — Fri, 08 Jul 2022 14:54:06 GMT

Hi,

I managed to print the data. I realized that the amount of print statements has an influence on the data distortion.

If I print my data in a loop in my data_handler(), the result is an almost perfect sine wave.

Printing in the data_handler() AND the queue_data() function will not work (only the prints in the data_handler() will show up), I have to remove the log statement in the data_handler() and add it in the queue_data(). When I plot the data here, the sinus is still recognizable, but already distorted:

What could be the reason for that?

My guess is, that while I'm processing the data in queue_data(), the data_handler() is called again and overwrites the data in mp_block_to_check while I'm still processing it.

for your reference, I'm adding my main loop, which checks if data has been written to mp_block_to_check by the data_handler() and, if yes, passes the address to queue_data().

// variables are declared in the beginning of the file as global variable
// I just add it here for reference
static uint32_t const * volatile mp_block_to_check = NULL;
static uint8_t m_array[243] = {0};

// my main loop, simplyfied to the most important parts
for (;;)
{
    if (mp_block_to_check)
    {
        queue_data(mp_block_to_check);
        mp_block_to_check = NULL;
    }

    //get data from the queue
    err_code = nrf_queue_read(&m_queue, &m_array, sizeof(m_array));
    if ((err_code != NRF_SUCCESS) &&
            (err_code != NRF_ERROR_INVALID_STATE) &&
            (err_code != NRF_ERROR_RESOURCES) &&
            (err_code != NRF_ERROR_BUSY) &&
            (err_code != BLE_ERROR_GATTS_SYS_ATTR_MISSING) &&
            (err_code != NRF_ERROR_NOT_FOUND)
       )
    {
        APP_ERROR_CHECK(err_code);
    }

    // send data via BLE
    if (err_code != NRF_ERROR_NOT_FOUND)
    {
        err_code = ble_aas_value_update(&m_aas, &m_array);
        if ((err_code != NRF_SUCCESS) &&
            (err_code != NRF_ERROR_INVALID_STATE) &&
            (err_code != NRF_ERROR_RESOURCES) &&
            (err_code != NRF_ERROR_BUSY) &&
            (err_code != BLE_ERROR_GATTS_SYS_ATTR_MISSING)
           )
        {
            APP_ERROR_CHECK(err_code);
        }
        else if (err_code == NRF_ERROR_RESOURCES)
        {
            ble_ready = false;
            while (!ble_ready)
            {
                idle_state_handle();
            }
            err_code = ble_aas_value_update(&m_aas, &m_array);
            if ((err_code != NRF_SUCCESS) &&
                (err_code != NRF_ERROR_INVALID_STATE) &&
                (err_code != NRF_ERROR_RESOURCES) &&
                (err_code != NRF_ERROR_BUSY) &&
                (err_code != BLE_ERROR_GATTS_SYS_ATTR_MISSING)
               )
            {
                APP_ERROR_CHECK(err_code);
            }
        }
    }
}

The function queue_data() is already included in my initial post. ble_aas_value_update just sends the data via BLE.

Any idea what could cause the data distrotion and how to improve my code to avoid that?

RE: I2S: Bit-Alignment in 24bit Mono mode

Einar Thorsrud — Fri, 08 Jul 2022 12:54:11 GMT

Hi,

If you need to log a lot of data fast you could consider not using deferred logging (that might cause timing problems for you app, but if would make logging more efficient). You could also increase buffer sizes in sdk_config.h both for RTT and the logger module. And lastly, perhaps you don't need to log much/for a long time if this is consistent?

RE: I2S: Bit-Alignment in 24bit Mono mode

Moritz_S — Fri, 08 Jul 2022 12:29:56 GMT

Hi,

thanks for the info. Could you tell me how to log a large array? I was trying with RTTLogger (which basically works for simple debug messages), but when it comes to logging the data array the chip freezes (All LEDs on). I was trying NRF_LOG_INFO() and NRF_LOG_HEXDUMP_INFO().

I was using

NRF_LOG_HEXDUMP_INFO(mp_block_to_check,(I2S_DATA_BLOCK_WORDS*4));

in the data_handler which is provided in my initial post. mp_block_to_check points towards p_released->p_rx_buffer and I2S_DATA_BLOCK_WORDS is the size of this buffer in uint32_t samples.

RE: I2S: Bit-Alignment in 24bit Mono mode

Einar Thorsrud — Fri, 08 Jul 2022 09:49:35 GMT

[quote user="Moritz_S"]In the meantime, could it be that BLE and I2S interfere with each other? That some BLE interrupts cause the I2S to not read correcly from the bus?[/quote]

The I2S peripheral use DMA, so the CPU is not used during a transaction, so BLE (or other) activity should not cause any problems in that case. But the pre- and post processing could potentially be delayed if higher priority interrupts happen, including BLE related from the SoftDevice. (It should be quick to check if this is related though, by simply stripping away the BLE part and logging the samples via for instance RTT to check if there is any difference)

RE: I2S: Bit-Alignment in 24bit Mono mode

Moritz_S — Fri, 08 Jul 2022 09:30:39 GMT

Hi Einar,

thanks for your reponse. I verified now that my data is in fact left aligned, so discarding the first 8 bits should be correct and not cause this problem.

I also checked the data that are received by the i2s, i.e., I checked the data in p_released->p_rx_buffer in the data_handler(). Turns out that the data is already corrupted here - I'm expecting a sine wave, but the signal I receive is far from that. I will try to create some plots of the logged data and post them the coming days.

In the meantime, could it be that BLE and I2S interfere with each other? That some BLE interrupts cause the I2S to not read correcly from the bus?

RE: I2S: Bit-Alignment in 24bit Mono mode

Einar Thorsrud — Wed, 29 Jun 2022 11:46:35 GMT

Hi,

It is not clear to mere where the data gets corrupted (in one way or another). Can you try to log the data both when received via I2S, and when you have packed it for BLE transfer and when received just to pinpoint where things get mixed up, to verify if this is an issue of alignment or something else?

Regarding I2S_CONFIG_ALIGN 0 here means left-aligned, so you should set to 1 if you want right-aligned and use this when configuring the driver (it is mapped to NRFX_I2S_CONFIG_ALIGN, which in turn is used in NRFX_I2S_DEFAULT_CONFIG). If you don't use this and instead provide your ow struct to nrf_drv_i2s_init(), then you need to update the alignment there to change it.