Page 2 of 3
Re: DS18B20 CRC error
Posted: Sat Dec 04, 2021 8:13 pm
by davef
I will try your implementation.
Thank you.
Re: DS18B20 CRC error
Posted: Sun Dec 05, 2021 11:11 am
by pythoncoder
Looking at the official driver I can't see how that can lock up either. It's possible that an electrical problem is causing the OneWire driver to lock up, in which case Robert's driver may also be vulnerable.
Re: DS18B20 CRC error
Posted: Sun Dec 05, 2021 5:13 pm
by davef
It will take a week or so before I know as I usually get one or two lock-ups/week.
As I was not running Roberthh's code when this problem surfaced would not <CRC error> be returned from the "official" onewire driver on a CRC error?
Shouldn't a driver not tolerate this sort of error?
Thanks
Re: DS18B20 CRC error
Posted: Sun Dec 05, 2021 5:41 pm
by davef
Looks like this was a hot-topic here:
https://forum.pycom.io/topic/5330/onewi ... -US&page=2
a few years ago. And nothing after that.
One comment made in that topic
P.S.: By the way, you will also have to turn off the garbage collector while reading digital sensors like outlined within [2]. Otherwise, things will probably also go south.
Is this relevant?
Re: DS18B20 CRC error
Posted: Sun Dec 05, 2021 5:49 pm
by Roberthh
Depends. The critical phase is readbit. That one does not create new objects during reading one bit, so GC won't be triggered form that. If you have other activity going on, like WiFi with callbacks, as in the case you cite with Pycom devices, that may trigger GC.
Re: DS18B20 CRC error
Posted: Sun Dec 05, 2021 6:18 pm
by davef
WiFi off, only one log sent per day.
Re: DS18B20 CRC error
Posted: Thu Dec 09, 2021 1:06 am
by davef
Roberthh,
I get significantly more "watchdog timeouts" using your ds18x20.py and onewire.py More like one every few hours rather than 1 or 2 a week. As a test I am going to substitute another DS18B20 for the one that is causing the grief.
I found this thread
viewtopic.php?f=16&t=2564&p=53667&hilit=CRCError#p53667where you mention catching CRCError. I failed in trying that then had a look through your ds18x20.py and onewire.py and could not see any text CRCError.
What would generate the message CRCError?
Even though it could be a faulty sensor should not the driver be able to tolerate it, generate a message, bail-out the whole OneWire part and resume normal code execution?
Re: DS18B20 CRC error
Posted: Thu Dec 09, 2021 7:41 am
by Roberthh
What would generate the message CRCError?
Line 56 in ds18x20.py:
Code: Select all
assert self.ow.crc8(self.buf) == 0, 'CRC error'
Re: DS18B20 CRC error
Posted: Thu Dec 09, 2021 8:41 am
by davef
How does:
Code: Select all
assert self.ow.crc8(self.buf) == 0, 'CRC error'
end up throwing a CRCError exception.
Code: Select all
for rom in roms:
try:
print (ds.read_temp (rom), end = '|')
except CRCError:
print("CRC error reading the termperature, unit", rom)
There must be some part of the "translation" process I am not aware of. Is there a list keywords that are used in assert statements that are then called by some keywords in except statements?.
Using your code I was not able to work out how to display what the actual errors were.
Also, after replacing the One wire sensor, your ds18x20.py and onewire.py has been running for the last 12 hours which is suggesting that it was the sensor that was acting up.
Re: DS18B20 CRC error
Posted: Thu Dec 09, 2021 8:53 am
by Roberthh
The assert statement causes an AssertionError when the expression in the statement is False. The text with the AssertionError is given in the assert statetment. The AssertionError is caught in read_temp(), so you should never see an CRCError exception. You could change the code in read_temp() to raise a CRC Error exception instead of returning None, or change read_scratch() to raise a CRC error in case of a wrong CRC instead of assert. Like:
Code: Select all
if self.ow.crc8(self.buf) != 0:
raise CRCError