user88066: I'm trying to use the DS18B20 sensor with Arduino Nano RP2040.
No matter which library I use, it seems to crash MbedOS as soon as the driver is initialized. I get 4 short and 4 long flashes of the orange LED, which as I found somewhere indicates a crash.
I was trying with DS18B20 library (https://github.com/matmunk/DS18B20) as well as the DallasTemperature one (https://github.com/milesburton/Arduino-Temperature-Control-Library).
At first I suspected that the issue is in my code as it interfaces with multiple different devices (EEPROM, SHT30, etc.) and this may interfere with 1-wire interface, but if I upload just the examples from these libraries the effect is the same.
I know that the Arduino is OK, as it can run other code absolutely fine, and the sensor is OK as well since I can read it with RaspberryPi.
Does anyone have similar problems? Is there some workaround?

user70020: Test Setup
I have wired an DS18B20+ to an RPI Pico and used a 4.7K pullup. The RPI Pico is a stand-in for your board. It uses the  arduino:mbed_rp2040:pico core rather than the arduino:mbed_nano:nanorp2040connect that yours does. However, I'm guessing they're similar enough.
Test result
When I attempt the to use the matmonk DS18B20 library you mention, I see similar pattern on the RPI Pico's onboard LED. Just the attempt to construct the object was sufficient to crash. Construction fairly directly defers to the OneWire library. So, I tried the OneWire library's own example for reading the DS18B20 (with some appropriate modification) and it crashes in the same manner. This lead to searching for and finding issues for the RP2040 on the OneWire github page resulting in (among others) this find. The answer mentions OneWireNG.
The OneWireNG DallasTemperature example works
Or rather, it's the library that works. But, this is the relevant example for it that works for me. I made the following modifications.

All Serial usages were replaced with SerialUSB because I am using the USB connection for the Serial Monitor (well, a terminal emulator).

I changed the one wire object to use GPIO28 because it was conveniently close to the pins where I was picking up 3.3V and GND: OneWire  ds(28);


It seems plausible that you could change the #include <DS18B20.h> usages in the two libraries you cited to #include "OneWireNg_CurrentPlatform.h" and find that they then work fine. I have not tried this yet. If that's of particular interest to you I will try it and update(Update below). However, this stock example from the OneWireNG library is not crashing and is printing temperatures that rise and fall expected when I manipulate the temperature of the sensor.
OneWireNg with Matmunk and DallasTemperature libraries
In general
It turns out that it is unnecessary to modify libraries that were using the original OneWire, not even just changing the #include. Despite the OneWireNg example using "OneWireNg_CurrentPlatform.h" it also provides a OneWire.h header. It is sufficient to have OneWireNg installed but the original OneWire library must uninstalled (or moved out of the libraries directory) so as not to confuse the build process into selecting the original library based on the header name over the OneWireNg library. The OneWireNg authors may have used the OneWireNg specific header in the examples to avoid this problem wit their examples when both libraries were installed. They've gone out of their way to make it compatible with the original, but below are reports of specific tests with the two libraries mentioned anyway.
Matmunk library with OneWireNg
With OneWireNg installed and the original OneWire not installed, the Multiple example form the matmunk library worked with the same minor modifications mentioned before (I used pin 28 rather than 2 and SerialUSB rather than Serial). In case your wondering the only reason why I switched from testing Single to Multiple is the latter didn't require that I first find and enter my part's address. That example is printing temperatures that rise and fall in accordance with manipulation of the sensor.
DallasTemperature with OneWireNg
Likewise I tested with the Multiple example from the DallasTemperature library. Same kind of modifications to the example. I changed ONE_WIRE_BUS to 28 for my setup. I changed Serial to SerialUSB. And runs normally and prints expected temperatures under manipulation of the sensor.

88066: <p>I'm trying to use the DS18B20 sensor with Arduino Nano RP2040.
No matter which library I use, it seems to crash MbedOS as soon as the driver is initialized. I get 4 short and 4 long flashes of the orange LED, which as I found somewhere indicates a crash.</p>
<p>I was trying with DS18B20 library (<a href="https://github.com/matmunk/DS18B20" rel="nofollow noreferrer">https://github.com/matmunk/DS18B20</a>) as well as the DallasTemperature one (<a href="https://github.com/milesburton/Arduino-Temperature-Control-Library" rel="nofollow noreferrer">https://github.com/milesburton/Arduino-Temperature-Control-Library</a>).<br />
At first I suspected that the issue is in my code as it interfaces with multiple different devices (EEPROM, SHT30, etc.) and this may interfere with 1-wire interface, but if I upload just the examples from these libraries the effect is the same.</p>
<p>I know that the Arduino is OK, as it can run other code absolutely fine, and the sensor is OK as well since I can read it with RaspberryPi.</p>
<p>Does anyone have similar problems? Is there some workaround?</p>
 70020: <h4>Test Setup</h4>
<p>I have wired an DS18B20+ to an RPI Pico and used a 4.7K pullup. The RPI Pico is a stand-in for your board. It uses the  <code>arduino:mbed_rp2040:pico</code> core rather than the <code>arduino:mbed_nano:nanorp2040connect</code> that yours does. However, I'm guessing they're similar enough.</p>
<h4>Test result</h4>
<p>When I attempt the to use the <a href="https://github.com/matmunk/DS18B20" rel="nofollow noreferrer">matmonk DS18B20 library</a> you mention, I see similar pattern on the RPI Pico's onboard LED. Just the attempt to <a href="https://github.com/matmunk/DS18B20/blob/1.0.0/examples/Single/Single.ino#L6" rel="nofollow noreferrer">construct the object</a> was sufficient to crash. Construction fairly directly <a href="https://github.com/matmunk/DS18B20/blob/1.0.0/src/DS18B20.cpp#L3-L6" rel="nofollow noreferrer">defers to the OneWire</a> library. So, I tried the OneWire library's own <a href="https://github.com/PaulStoffregen/OneWire/blob/v2.3.7/examples/DS18x20_Temperature/DS18x20_Temperature.ino" rel="nofollow noreferrer">example for reading the DS18B20</a> (with some appropriate modification) and it crashes in the same manner. This lead to searching for and finding issues for the RP2040 on the OneWire github page resulting in (among others) <a href="https://github.com/PaulStoffregen/OneWire/issues/105" rel="nofollow noreferrer">this find</a>. The answer mentions <a href="https://github.com/pstolarz/OneWireNg/" rel="nofollow noreferrer">OneWireNG</a>.</p>
<h4>The OneWireNG <a href="https://github.com/pstolarz/OneWireNg/blob/0.12.2/examples/arduino/DallasTemperature/DallasTemperature.ino" rel="nofollow noreferrer">DallasTemperature example</a> works</h4>
<p>Or rather, it's the library that works. But, this is the relevant example for it that works for me. I made the following modifications.</p>
<ul>
<li><p>All <code>Serial</code> usages were replaced with <code>SerialUSB</code> because I am using the USB connection for the Serial Monitor (well, a terminal emulator).</p>
</li>
<li><p>I changed the one wire object to use GPIO28 because it was conveniently close to the pins where I was picking up 3.3V and GND: <code>OneWire  ds(28);</code></p>
</li>
</ul>
<p><s>It seems plausible <strong>that you could change the <code>#include &lt;DS18B20.h&gt;</code> usages</strong> in the two libraries you cited to <code>#include &quot;OneWireNg_CurrentPlatform.h&quot;</code> and find that they then work fine. I have not tried this yet. If that's of particular interest to you I will try it and update</s>(<strong>Update below</strong>). However, this stock example from the OneWireNG library is not crashing and is printing temperatures that rise and fall expected when I manipulate the temperature of the sensor.</p>
<h4>OneWireNg with Matmunk and DallasTemperature libraries</h4>
<h5>In general</h5>
<p>It turns out that it is <em>unnecessary</em> to modify libraries that were using the original OneWire, not even just changing the <code>#include</code>. Despite the OneWireNg example using <code>&quot;OneWireNg_CurrentPlatform.h&quot;</code> it also provides a OneWire.h header. It is sufficient to have OneWireNg installed but <strong>the original OneWire library must uninstalled</strong> (or moved out of the libraries directory) so as not to confuse the build process into selecting the original library based on the header name over the OneWireNg library. The OneWireNg authors may have used the OneWireNg specific header in the examples to avoid this problem wit their examples when both libraries were installed. They've gone out of their way to make it compatible with the original, but below are reports of specific tests with the two libraries mentioned anyway.</p>
<h5>Matmunk library with OneWireNg</h5>
<p>With OneWireNg installed and the original OneWire <em>not</em> installed, the <a href="https://github.com/matmunk/DS18B20/blob/1.0.0/examples/Multiple/Multiple.ino" rel="nofollow noreferrer">Multiple example</a> form the matmunk library worked with the same minor modifications mentioned before (I used pin 28 rather than 2 and <code>SerialUSB</code> rather than <code>Serial</code>). In case your wondering the only reason why I switched from testing Single to Multiple is the latter didn't require that I first find and enter my part's address. That example is printing temperatures that rise and fall in accordance with manipulation of the sensor.</p>
<h5>DallasTemperature with OneWireNg</h5>
<p>Likewise I tested with the <a href="https://github.com/matmunk/DS18B20/blob/1.0.0/examples/Multiple/Multiple.ino" rel="nofollow noreferrer">Multiple example from the DallasTemperature library</a>. Same kind of modifications to the example. I changed <code>ONE_WIRE_BUS</code> to <code>28</code> for my setup. I changed <code>Serial</code> to <code>SerialUSB</code>. And runs normally and prints expected temperatures under manipulation of the sensor.</p>
