search

kellerkindt / onewire

OneWire bus implementation in Rust using embedded-hal
Apache License 2.0
35 stars 14 forks source link

LSB of scratchpad[0] is always high, causing CRC checks to occasionally fail #9

Closed fuchsnj closed 4 years ago

fuchsnj commented 4 years ago

I am getting a significant number of CRC mismatches while testing a ds18b20 with an stm32f103. I've tested with 4+ different ds18b20's, and also confirmed they work with an Arduino nano (not using this library).

I disabled the CRC checking, and dumped the scratchpad memory, and it appears that the data coming from the ds18b20 is correct, but the CRC check is failing. Reading the scratchpad multiple times always returns the exact same data.

Here is some sample data I captured of temp data read from the sensor. Changes in scratchpad index 6 seems to cause a CRC mismatch. I'm still reading through the datasheets to understand how the CRC function works, it might be an easy fix.

Raw Temp Value CRC match? Scratchpad Data (Decimal)
355 true [99, 1, 75, 70, 127, 255, 13, 16, 21]
355 false [99, 1, 75, 70, 127, 255, 14, 16, 3]
353 true [97, 1, 75, 70, 127, 255, 15, 16, 2]
353 false [97, 1, 75, 70, 127, 255, 16, 16, 181]
351 true [95, 1, 75, 70, 127, 255, 1, 16, 155]
351 false [95, 1, 75, 70, 127, 255, 2, 16, 141]

The device id for these samples is [40, 255, 21, 32, 11, 0, 0, 87] (decimal)

fuchsnj commented 4 years ago

I tested a bunch between an Arduino and my STM32F103. It actually looks like the first byte of the scratchpad is being occasionally read wrong by the STM32. The least significant bit is always 1 (it's always an odd number). For all of the rows where CRC match is false, if you set the LSB to 0, the CRC matches. I'm still not sure what is causing this though.

fuchsnj commented 4 years ago

With the exact same wiring on the same device, when I use an Arduino library to interface with the ds18b20 it works fine, but when using this library, the LSB of scratchpad[0] is always 1 (causing the CRC check to fail ~50% of the time). So I'm fairly confident I've ruled out hardware issues, but this also isn't an issue with the CRC algorithm so I'll update the issue name.

fuchsnj commented 4 years ago

I wrote my own onewire implementation, and used all of the timing values provided by the Maxim 1-wire document (https://www.maximintegrated.com/en/design/technical-documents/app-notes/1/126.html) and all of the readings look correct for me now. I suspect there is a timing issue in this library, since it doesn't use the recommended timings in some places. I'll publish my implementation in the next few weeks when it's more complete if you want to reference it.

fuchsnj commented 4 years ago

The root cause was timing issues because the default clock speed on the stm32f103 (which I was using for testing) was too low. See https://github.com/stm32-rs/stm32f1xx-hal/issues/169 for more details. Closing since this shouldn't be an issue with this library.

kellerkindt commented 4 years ago

Hi there, great to hear you could fix your issue. I know that using DelayUs is not great, and it can cause runtime issues on hardware that is faster/slower as the one I am testing it on locally (stm32f103) #11.