Trouble initializing and communicating after other code changes

[chmorgan]

Hi.

First off, great library. I had no trouble getting my external ds18b20 module working.
I'm using the ds18b20 in external supply mode so I'm providing a dedicated 3.3v supply to the device. My data line has a 4.7k pullup per the datasheet recommendation.

Before some recent code changes to totally unrelated code I was seeing only very rare crc errors. After some recent code changes to other tasks the device isn't detected at power up even after three retries.

As the change was outside of the temperature reading task that I'm using to call the ds18b20 read function I suspect a timing change is causing the issue here but I'm not seeing anything particularly suspicious in my traces. Any thoughts where to look? I'm wondering if there is other timing sensitive code in your library that may need to be protected from interruption from outside tasks, or maybe if its related to a lack of full gpio pin configuration? I'm not doing any gpio configuration in my code and it looks like the esp32-owb only does direction and level configuration and doesn't touch the optional pullup/pulldowns that are on most gpio pins.

[chmorgan]

Well I know a bit more about 1-wire now. Is the commented out line below a bug? It looks like _address_device() was being issued twice. I noticed it on my scope because a device reset was occurring immediately after a 0xCC (skip rom) was being sent and that didn't make sense.

float ds18b20_read_temp(const DS18B20_Info * ds18b20_info)
{
    float temp = 0.0f;
    if (_is_init(ds18b20_info))
    {
        const OneWireBus * bus = ds18b20_info->bus;
        if (_address_device(ds18b20_info))
        {
            // read measurement
//            _address_device(ds18b20_info);  <---------------- shouldn't this call be removed?
            owb_write_byte(bus, DS18B20_FUNCTION_SCRATCHPAD_READ);

I can submit a PR if you agree.

Continuing to debug. I'm still seeing CRC failed on reads even though the signal on the scope looks quite clean.

[chmorgan]

Alright, I did find a few things that didn't look good on the bus and opened a pull request for that, DavidAntliff/esp32-owb#1

But I'm still seeing crc errors and all of the of the timing looks great. Still not seeing why I'm getting CRC errors. Now I'm wondering if the crc is somehow broken for particular values. I'll have to continue to debug to see what is going on.

[DavidAntliff]

Thanks for your feedback. That repetition of _address_device does look suspicious and I think it was a mistake to call it twice. A PR to fix that would be great if you're also able to test with hardware.

Not sure about the CRC - I do sometimes see CRC errors with my five sensors, maybe one or two a day. I had one device that showed more errors than the others, and it turned out to have a slightly dodgy soldering joint. After I fixed that, the CRC error rate across all devices seemed to be about equal.

I don't have my temp sensors set up properly at the moment due to another project, however since you're showing a welcome interest, I will see about getting things up and running in the next few days so I can help you out.

[chmorgan]

Closing as the crc errors were due to interrupt handling causing the gpio sampling to be out of spec in some cases. No issues when using the rmt based driver.