Description
Describe the bug
When testing the sample code using the aosong driver on an Arduino Giga Wifi R1 with a DHT11 connected to pin 7, the driver is reporting incorrect humidity and temperature due to a bit shift caused by the change made for #83192. A line in the driver was removed that set the pin to logic low (HIGH value due to GPIO_ACTIVE_LOW) which is required to let the DHT11 take over the single bus line. Due to that change, the next code line immediately returns when waiting for the startup protocol values, thus causing it to read one of the protocol signals as part of the first bit of the data transmission.
By reverting the last change, it works fine on the Arduino. However, the symptoms in #83192 will reappear unless a different change is made.
Sample Code: samples/sensor/dht_polling
Sensor Driver: "aosong,dht" (for use with aosong's DHT11) zephyr/drivers/sensor/aosong/dht/dht.c
Board/Target: arduino_giga_r1/stm32h747xx/m7
App/Board Overlay:
/*
* Device Tree overlay for DHT sensor sample on Arduino Giga R1 WiFi (M7 Core)
* Connect the DHT sensor's data pin to Arduino pin D7 (PB4).
* For DHT11 Sensor.
*/
/ {
aliases {
/* Assign dht0 alias to our defined DHT sensor node */
dht0 = &dht_sensor;
};
/* Define the DHT sensor node */
dht_sensor: dht_sensor {
compatible = "aosong,dht";
label = "DHT_SENSOR";
/* Specify the GPIO pin connection and enable the pull-up */
dio-gpios = <&gpiob 4 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
/* Enable the device */
status = "okay";
};
};
Broken output:
*** Booting Zephyr OS build v4.1.0-3126-gbef5abd29344 ***
DHT_SENSOR: temp is 10.99 °C humidity is 144.99 %RH
DHT_SENSOR: temp is 10.99 °C humidity is 144.99 %RH
Output after reverting change:
*** Booting Zephyr OS build v4.1.0-3126-gbef5abd29344 ***
DHT_SENSOR: temp is 22.99 °C humidity is 33.99 %RH
DHT_SENSOR: temp is 22.99 °C humidity is 33.99 %RH
To Reproduce
- Connect an aosong DHT11 data line to pin 7 on an Arduino Giga Wifi R1 and the appropriate GND and VCC.
- Perform the build:
west build -p -b arduino_giga_r1/stm32h747xx/m7 samples\sensor\dht_polling - Flash the device:
west flash
Expected behavior
We expect the output to be like the reverted change indicates:
*** Booting Zephyr OS build v4.1.0-3126-gbef5abd29344 ***
DHT_SENSOR: temp is 22.99 °C humidity is 33.99 %RH
DHT_SENSOR: temp is 22.99 °C humidity is 33.99 %RH
Impact
Without reverting this change, the sensor does not report correct values.
Logs and console output
Adding some debug statements to dump the signal durations and bytes clearly shows the bit shift.
Bad reads: (notice the 55us signal duration which is part of the startup protocol from the sensor caused by the removal of the code)
[00:00:02.021,000] �[0m<dbg> DHT: dht_sample_fetch: Signal Durations (us):
55 16 17 45 17 17 17 45 17 17 17 16 17 17 17 17 |U..E...E ........
18 17 17 17 45 17 45 45 45 17 16 17 17 17 17 16 |....E.EE E.......
18 17 17 45 45 45 17 16 |...EEE.. �[0m
[00:00:02.021,000] �[0m<dbg> DHT: dht_sample_fetch: Byte Values (h_dig) (h_dec) (t_dig) (t_dec) (CS):
91 00 0b 80 1c |..... �[0m
DHT_SENSOR: temp is 10.99 °C humidity is 144.99 %RH
Good reads (code reverted):
[00:00:02.021,000] �[0m<dbg> DHT: dht_sample_fetch: Signal Durations (us):
17 17 45 17 17 16 45 17 17 17 17 16 17 17 17 18 |..E...E. ........
17 17 17 45 17 45 45 45 17 17 17 17 16 17 17 18 |...E.EEE ........
16 17 45 45 45 17 17 43 |..EEE..C �[0m
[00:00:02.021,000] �[0m<dbg> DHT: dht_sample_fetch: Byte Values (h_dig) (h_dec) (t_dig) (t_dec) (CS):
22 00 17 00 39 |"...9 �[0m
DHT_SENSOR: temp is 22.99 °C humidity is 33.99 %RH ffff
Environment (please complete the following information):
- OS: Windows
- Toolchain: Zephyr SDK
- Commit: Current tip (must be since broken commit at link: https://github.com/zephyrproject-rtos/zephyr/pull/83192/commits/9eeb60c2cbecc0859c003c956e38fd09c33bd26b)
Additional context
I believe the correct fix for #83192 would be to have the user specify "CONFIG_DHT_LOCK_IRQS=y" with a different change to dht.c moving the irq_lock prior to the start signal being sent to the pin. I believe the speed of their board along with the bad placement of the original irq_lock caused the timing issue they were experiencing (meaning even if they did add the irq config, with the bad placement of the irq_lock, it would have caused a very large delay and they would still have a problem).
I will be submitting the proposed changes.