DPS310 will trigger an Assert in raw_to_scaled(int32_t raw, uint8_t rate) function after running for a long time.

[Uvamosk]

Hello,
I was wondering if anyone could help me figure out what is going on here.

I am using a DPS310 that every 1 second I use to take a Temperature Sample and a Pressure Sample.
Code works like this

1. One Second is up
2. Start Temp read
3. Check for Ready bit
4. Retrieve Temp Reading
5. Start Pressure read
6. Check for Ready bit
7. Retrieve Pressure Reading

This code will run for a long period of time usually more than 10 minutes have seen up to 2 hours then I'll get an Assert as follows.
assert failed: raw_to_scaled dps310.c:745 (rate <= N_SCALE_FACTORS - 1)
(I have added some debug code so the line number might be slightly off)

This line of code lives in the function raw_to_scaled(int32_t raw, uint8_t rate).

Some times a Temperature Read causes that function to trigger the assert some times its a Pressure Read so both some how end up getting a rate returned that is out of bounds.

I have added Debug code to print out the rate that is being passed to raw_to_scaled function. I have seen the value 13 and value 15 passed to it when the Assert gets triggered.

I then added code to fire a I/O pin when the value is greater than the Assert trigger value. This way I could check the i2c bus with a scope.
What I found was the following.
The scope triggered on the GPIO pin that was toggled when the Assert triggered. The rate value passed was 15.
The dps310_get_oversampling_p(dev, &P_rate) function in dps310_read_pressure(dps310_t *dev, float *pressure) is what triggered the assert. This function queries register (DPS310_REG_PRS_CFG) 0x06 and masks it with 0x1111 to get the Oversampling rate.
When I check for this on the scope in the I2C bus data I see DPS310_REG_PRS_CFG returned 0x04 which was what it should have been. As I have both temperature and pressure set to 16 times oversampling.

So now I'm left really confused because the data on the bus is correct but the value being passed to the raw_to_scaled function is 15 and the fact it happens after running for a long time makes me more confused.

[UncleRus]

@trombik It looks like bug to me

[Uvamosk]

@UncleRus if I have questions about why things are done a certain way in the dps310.c who do I ask? I'm new to github and doing stuff like this in general so please excuse my confusion.

[trombik]

Probably, you are right. I have been in a private trouble, and I will be for another month or two. I cannot narrow down the issue at the moment. Sorry.

[trombik]

In general, who you should ask is the code owner(s). Please see .eli.yml in the directory of the component. Asking help here is totally okay as well.

[Uvamosk]

I posted over at espressif's forums (https://esp32.com/viewtopic.php?f=13&t=38274).
I found two others that have experienced similar issues.
I have also drilled deeper into the I2C code to get as close to the IDF driver as possible to make sure I wasn't getting corruption somewhere else in the i2cDev library chain which I doubt is the problem.
within i2cdev.c I added debug output code to check that the value from the IDF function that controls the i2c.
It returns values that match the DPS310 library data being returned so doesn't seem to be an issue from here up to the DPS310 library. Which I suspected.
Is there any other suggestions of things to look into. As apparently the i2c of the ESP32 has some sort of hardware/software (IDF) glitch people run into.

esp_err_t i2c_dev_read(const i2c_dev_t *dev, const void *out_data, size_t out_size, void *in_data, size_t in_size)
   {
    if (!dev || !in_data || !in_size) return ESP_ERR_INVALID_ARG;

    SEMAPHORE_TAKE(dev->port);

    esp_err_t res = i2c_setup_port(dev);
    if (res == ESP_OK)
    {
        i2c_cmd_handle_t cmd = i2c_cmd_link_create();
        if (out_data && out_size)
        {
            i2c_master_start(cmd);
            i2c_master_write_byte(cmd, dev->addr << 1, true);
            i2c_master_write(cmd, (void *)out_data, out_size, true);
        }
        i2c_master_start(cmd);
        i2c_master_write_byte(cmd, (dev->addr << 1) | 1, true);
        i2c_master_read(cmd, in_data, in_size, I2C_MASTER_LAST_NACK);
        i2c_master_stop(cmd);

        res = i2c_master_cmd_begin(dev->port, cmd, pdMS_TO_TICKS(CONFIG_I2CDEV_TIMEOUT));
        if (res != ESP_OK)
            ESP_LOGE(TAG, "Could not read from device [0x%02x at %d]: %d (%s)", dev->addr, dev->port, res, esp_err_to_name(res));

        // Added this Debug line to check what data is retrieved from the I2C bus, I am only expecting 1 byte
        printf("i2cdev.c L303: in_data %02X\n", *(uint8_t *) in_data);

        i2c_cmd_link_delete(cmd);
    }

    SEMAPHORE_GIVE(dev->port);
    return res;
}

[Uvamosk]

@trombik
Thank you for the help! Also no worries about trying to look at it. I'm still trying to collect enough proof that something is wrong.
I honestly at this point think it is something else because I have worked my way back through your code to the last function you call before things get handed off to the i2cdev.c library which is this function.

esp_err_t _read_reg_mask(i2c_dev_t *dev, uint8_t reg, uint8_t mask, uint8_t *val)
{
    uint8_t reg_value = 0;

    CHECK_ARG(dev && val);

    I2C_DEV_TAKE_MUTEX(dev);
    I2C_DEV_CHECK(dev, _read_reg_nolock(dev, reg, &reg_value));
    I2C_DEV_GIVE_MUTEX(dev);
    *val = (reg_value & mask) >> _count_trailing_zero_bits(mask);
    
    ///// R: Register, M: Mask, RV: Register Value, V: Value after trailing Zeros removed
   ///// I added this printf statement so I didn't need to turn on ESP_LOG and get flooded LOG data
    printf("R: %02X M: %02X RV: %02X V: %02X\n", reg, mask, reg_value, *val);

    ESP_LOGV(TAG, "reg_value: %02X, val: %02X", reg_value, *val);
    return ESP_OK;
}

_read_reg_nolock() is just a wrapper for i2c_dev_read_reg() so didn't feel the need to go that low.
The diag data from the print statement shows the exact same data has the higher level functions in your code be it the correct data or corrupted.
So at this point I'm left wondering if there is a pointer issue or memory leak in some other library I am using.

So I'll keep trying to dig up what the issue might be and if I figure out anything related to the DPS310 library I'll let you know.
1 Last questions if I would like to contribute to the DPS310 code you wrote do I need to do a pull request and then just submit it for review?

[trombik]

Pull request is always welcome, but I cannot confirm that the PR really fix the issue at the moment.

[Uvamosk]

Fully understand that no problem. The changes I wanted to propose are not connected to this issue at hand so once I get this project far enough along and feel comfortable submitting my changes for review I'll do it and see what you think.
Thank you again for the help and for writing the DPS310 code.