1-Wire bad signal after DS18B20_CONVERT_T (0x44)

[The-Michael-R]

I have some trouble to get the 1-Wire up and running. I use my own code but the example fails the same way.

Setup: Pico-W, 1-Wire is connected as in the example (GPIO-Pin 15, 3,3kOhm Piull-Up), the single MAX31820 has connection to 3.3V supply via Pico-W pin 36 (not using the 'parasite power' feature).

The initialization is done successful and OW_MATCH_ROM works as expected (the device only answers to the right ROM pattern).

But after sending

ow_reset(&sTempSensor.sOneWire);
ow_send(&sTempSensor.sOneWire, OW_SKIP_ROM);
ow_send(&sTempSensor.sOneWire, DS18B20_CONVERT_T);

It seems that there is a kind of timeout in the sensor as it pulls the dataline high after some time. Which is longer than the max tCONV for the selected resolution (e.g. more that 800ms vs. 750ms for 12 bit) and the sensor returns:

ff - 07 - 4b - 46 - 7f - ff - 01 - 10 - 2f

in the scratchpad. The signal after the lines above looks like that: CursorA->B: 'SkipROM' CursorB->Invalid level 'Convert_T'

The 1.3V level appears only after the CONVERT_T command and strangely reasonable hard driven as changing the PullUp resistor changes the value only a little (1.3->1.6V with 1.7kOhm). After some time that voltage rises to 3.2V and requesting the scratchpad results in the above mentioned pattern.

[lurch]

ping @mjcross as the author of https://github.com/raspberrypi/pico-examples/tree/master/pio/onewire (and for future reference, the forums are probably a more suitable place for this kind of question)

[mjcross]

@The-Michael-R You said that you are using a MAX31820, but it looks like you're sending it a DS18B20 command.

 ow_send(&sTempSensor.sOneWire, DS18B20_CONVERT_T);

[The-Michael-R]

@mjcross Thanks for the quick answer.

To my knowledge, the DS18B20 and the MAX31820 are very close to each other. The DS has a wider supply range and non-volatile memory. But the protocol and timings are identical (notice the wording). I checked multiple times all macros used but I fail to find a difference. Still, there might slipped something my view.

I think the change is due to the acquire of Dallas Semi by Analog Devices which then was acquired by Maxim Integrated. ...it's complicated ;-)

Edit: My code doesn't poll for the rising edge send by the sensor. Thus no read-access are visible in the scope picture. The code does a 850ms sleep there. Changing to polling does not change anything. Also as mentioned the unchanged example code fails as well,

[mjcross]

Ok thx for the heads up on the MAX31820 - I wasn’t aware. Not seen anything like that effect here; will try to reproduce it (poss. tmw)

[The-Michael-R]

No problem. If you thing you need some tests on my setup to check one or the other thing, I'm happy to help.

Not sure but the only idea I have is that the PIO lefts the output pin at strong '1' while the sensor drives '0' o or other way around. Thus the 1.5V on the data-lane. Especially as the "Convert T" command is the only one (except the not used 'Read Power Supply') with the last transmitted bit (MSB) is '0'. All other commands has a MSB = '1'. Maybe I'll spend some time tomorrow to check how the output pin is driven after the command is send.

[The-Michael-R]

Some update about this problem.

After looking for the reason why the level of the signal lane is that low I figured out that the load comes from the MAX31820. It seems that even with direct 3.3V supply it loads the signal line. So I reduced the pull-up resistor to 1kOhm which finally made the MAX31820 happy and it reports the temperature.

[mjcross]

OK good - I wasn't able to reproduce anything like that with the DS18B20.