Anyone able to reproduce this (hard lock w/ DHT22)

[GM-Script-Writer-62850]

I am using a Raspberry Pi PICO w/ a W5500

I found using dht on core 0 while core 1 is in use is a bad idea when using the W5500 network driver, you are gonna have a bad day

but that is not the issue here, i have DHT22s being read on core 1 while core 0 is running a input polling loop, the issue is sometimes when dht.measure() is run it never returns, furthermore even if i have core 0 check if a flag has been checked as seen below, not even this can recover form this lockup, maybe this is some king of memory overflow or corruption?

if it happens while thonny is connected you get no errors if you try to use the stop button it will not get into the pico, it has to be power cycled, would using the debug header be able to provide more details?

core 0:

ct=0
if watchdog:
  ct+=1
  if ct > 9000: # somehow the hardlock will survive this
    machine.reset() # clearly this is locked up as it has not been released in over 9 seconds for a ~200ms job
time.sleep_ms(1)

core 1:

watchdog=1
try:
  dht.measure()
except Exception as e:
  print(e)
watchdog=0

DHT22 Polling frequency is not a issue, i only read them about every 16 minutes

this can happen as soon as the 1st time reading a sensor, usually this will he hit in a few hours of running

Was using the nightly firmware from the 7th:

• W5500_EVB_PICO-20230407-unstable-v1.19.1-1009-gcfd3b7093.uf2
• here is my full_source_code.zip

Note that using this firmware (v2.0.0) it seems to be far more rare if ever: https://github.com/Wiznet/RP2040-HAT-MicroPython/releases

I may have had this happen on my pico W once, but i did not have a system hooked up to monitor it and the crash log was empty, though i had no thread locks for work array on that one in the interest of testing to see what happens, unless that would also not throw a error... the PICO W is reading the DHTs on core 0 and polling on core 1

[peterhinch]

From a brief look at your source you seem to be running uasyncio on core 1 while the blocking polling loop runs on core 0. I have never tested this arrangement: in my efforts uasyncio has run on core 0, with blocking code on core 1. I'm clutching at straws here but it might be worth trying this setup.

Is it feasible to run the whole thing under uasyncio on one core?

[GM-Script-Writer-62850]

You could as long as _thread is NOT used, the wizent network driver will take a crap if you try to use dht.measure on core 0 while using _thread (or maybe it is the dht module?)

i suspect when dht.measure locks interrupts the wiznet driver breaks as it sees core 1 is in use and opts to not use it, that driver is clearly not as nice to work with as the PICO W's driver (in my testing this applies to both wiznet's build and microython's build)

• DHT measure() locks up (core0) when _thread is running (core1) if WIZNET5K networking is enabled #10448

the idea of polling on a second core is to not have a blind spot in the polling from eg 250ms of dht.measure (nobody like to press button and it not see the button press)

• i tried using interrupts but said screw it when i had issues with EMI tripping it (florescent light fixtures) think Ferrite cores would help? i even have seen them hold a state over 30ms cause of them

note that the _thread lock only occurs while writing to the work array, it may have been a fluke but using the lock made it seems to make it go from 1 min run time to several hours of run time before crashing

[ADenislebel]

My issue with reading DHT22 sensor is probably not related but my routine to read 2 of them works fine on its own but when I call it from a main.py that does other functions, the DHT readings fail and never recover until I power down the Pico. A simple soft or hard reset does not clear the problem. The DHT reading routine is a PIO based in assembler that I got off Github. Perhaps the PIO get corrupted some maybe because it get cut of by my other processing constraints. I simply don't have the expertise to know! I don't expect an answer I simply giving info that might be related to your problem. I will monitor this post in case it can give me some insight on my problem.
Regards Denis

[GM-Script-Writer-62850]

are you saying when you read the sensor and it fails (timedout) it will never succeed again will you power-cycle the pico? i found a solution to that, you need to pull down the data pin AND cut VCC to the DHT22, then you can setup your DHT22 pin and it will work again, be sure to keep it down for a moment, supposedly you need at least 10ms

[ADenislebel]

Thanks I will give that a try...Denis

[GM-Script-Writer-62850]

you will probably want to power the DHT22 with a GPIO pin unless you are using 5v logic i would not suggest a transistor due to forward voltage drop

[ADenislebel]

Thanks but my hardware was not setup to drive the power for the DHT22s. I will continue to attempt to figure out the problem before I reconsider changing the wiring. By the way if I only run the code to read the sensors continuously it works all the time. Which tells me there is some kind of code runtime interaction that brings on the failure. Regards...Denis

…

On Wed, Apr 12, 2023 at 10:35 AM GM-Script-Writer-62850 < ***@***.***> wrote: are you saying when you read the sensor and it fails it will never succeed again will you power-cycle the pico? i found a solution to that, you need to pull down the data pin AND cut VCC to the DHT22, then you can setup your DHT22 pin and it will work again — Reply to this email directly, view it on GitHub <#11246 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEFK5EOBHTFHSGV6KVZYKYLXA24R7ANCNFSM6AAAAAAW3DTF44> . You are receiving this because you commented.Message ID: ***@***.*** com>

[GM-Script-Writer-62850]

by rewire i mean instead of using 3.3v for the DHT22, use a GPIO output pin as you can turn it off, in my testing you want to wait around 600ms before you try to read the DHT22 after powering it on (500ms will work, but may give bad data)

sadly this means using 2 GPIO pins per sensor, though you could just reset every sensor at once then you only need 1 pin for powering the sensors, but that feels dirty and you could use a 74HC4051 or CD74HC4067 mux chip to save GPIO pins if you are getting low and just need a few more

recovery sample code

class GPIO:
  class sensors:
    pins={}

name="what_i_named_my_sensor"
GPIO.sensors.pins[name] = { "pwr": Pin(A, Pin.OUT, value=1), "data":Pin(B), "DHT":None }
# you may find you need to setup the pin in the low state want a moment then set it high, depends on hte pin used in my exp
time.sleep_ms(666)
GPIO.sensors.pins[name]["DHT"]=dht.DHT22(GPIO.sensors.pins[name]["data"])

while 1:
  try:
    GPIO.sensors.pins[name]["DHT"].measure()
    print(GPIO.sensors.pins[name]["DHT"].temperature(),"C /", GPIO.sensors.pins[name]["DHT"].humidity(),"%")
  except:
    # reset sensor
    GPIO.sensors.pins[name]["DHT"]=None
    GPIO.sensors.pins[name]["pwr"].off()
    GPIO.sensors.pins[name]["data"].init(mode=Pin.OUT, value=0)
    time.sleep_ms(250) # wait for it to power off
    #bring sensor back up
    GPIO.sensors.pins[name]["pwr"].on()
    time.sleep_ms(666) wait for it to power on
    GPIO.sensors.pins[name]["DHT"]=dht.DHT22(GPIO.sensors.pins[name]["data"])
  time.sleep_ms(2000)

[ADenislebel]

I will start another post for my problem with DHT readings as its not core related and since I can read them forever while running a single py. My issues occur when I try calling the read function (py) from another main.py. When I do so the first reading works but all subsequent fail. I therefore believe its interaction related to using the PIO block that is being used for the low level driver I cloned from Github.
Thanks anyway..Denis

[ADenislebel]

Thanks for the tip!

…

On Sat, Apr 22, 2023 at 11:17 AM GM-Script-Writer-62850 < ***@***.***> wrote: by rewire i mean instead of using 3.3v for the DHT22, use a GPIO output pin as you can turn it off, in my testing you want to wait around 600ms before you try to read the DHT22 after powering it on (500ms will work, but may give bad data) sadly this means using 2 GPIO pins per sensor, though you could just reset every sensor at once then you only need 1 pin for powering the sensors, but that feels dirty and you could use a 74HC4051 or CD74HC4067 mux chip to save GPIO pins if you are getting low and just need a few more recovery sample code class GPIO: class sensors: pins={} name="what_i_named_my_sensor" GPIO.sensors.pins[name] = { "pwr": Pin(A, Pin.OUT, value=1), "data":Pin(B), "DHT":None } # you may find you need to setup the pin in the low state want a moment then set it high, depends on hte pin used in my exp time.sleep_ms(666) GPIO.sensors.pins[name]["DHT"]=dht.DHT22(GPIO.sensors.pins[name]["data"]) while 1: try: GPIO.sensors.pins[name]["DHT"].measure() print(GPIO.sensors.pins[name]["DHT"].temperature(),"C /", GPIO.sensors.pins[name]["DHT"].humidity(),"%") except: # reset sensor GPIO.sensors.pins[name]["DHT"]=None GPIO.sensors.pins[name]["pwr"].off() GPIO.sensors.pins[name]["data"].init(mode=Pin.OUT, value=0) time.sleep_ms(250) # wait for it to power off #bring sensor back up GPIO.sensors.pins[name]["pwr"].on() time.sleep_ms(666) wait for it to power on GPIO.sensors.pins[name]["DHT"]=dht.DHT22(GPIO.sensors.pins[name]["data"]) time.sleep_ms(2000) — Reply to this email directly, view it on GitHub <#11246 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEFK5EPSMNKI73HEPU6E2C3XCPZCBANCNFSM6AAAAAAW3DTF44> . You are receiving this because you commented.Message ID: ***@***.*** com>