Bad device on bus causes ds18b20_check_for_parasite_power to hang
lukecyca opened this issue · 4 comments
I have a DS18B20 that is malfunctioning. When it is plugged in to the bus, the call to ds18b20_check_for_parasite_power() hangs forever. I believe it is hanging in its call to _read_bits() hence why I have opened the issue here.
Obviously my malfunctioning device is the root cause here. However I think even a misbehaving bus should not cause this call to hang indefinitely.
The debug output is:
D (3428) ds18b20: ds18b20_check_for_parasite_power
E (3528) owb_rmt: rx_items == 0
D (3528) owb_rmt: _is_present 0
D (3528) ds18b20: owb_reset OK
D (3528) ds18b20: owb_write_byte(ROM_SKIP) OK
D (3528) ds18b20: owb_write_byte(POWER_SUPPLY_READ) OK
[hangs]
Edit: I am using RMT, not GPIO.
I've looked through the code and I can see a few places where a hang might be occurring, but without a malfunctioning device it's going to be hard for me to track it down decisively. Since you have such a device, do you think you might be able to move around a few strategic logging statements to see if you can work out which loop is not terminating, or which IDF function call is not returning, please?
It is hanging on this line: owb_rmt.c:284
rmt_item32_t *rx_items = (rmt_item32_t *)xRingbufferReceive(info->rb, &rx_size, portMAX_DELAY);
I'm assuming the fix is to change portMAX_DELAY to a reasonable timeout. Then rx_items will be null, the else will be taken below, and the correct error code applied.
There is a similar call in _reset() for which the timeout is 100 / portTICK_PERIOD_MS so I tried that. It seems to work well, and the rest of the error handling functions as expected.
Thank you for investigating further - thanks for the PR, looks good to me.