[Solved / Archived] Faulty Wittypi 4 mini ?

Not likely. White LED blinks when powered, tapping button to power the Pi, all these behavior are normal, which means the firmware is functioning well.

The problem is power did not get cut after shutdown. This is usually due to the voltage on TXD pin did not drop (to zero) after shutdown, which is an expected behavior from Pi.

The reason could be incorrectly configuration on serial port, or there is other hardware (strongly) pulling up TXD.

Thanks for your answer.

I have now attached a multimeter between GND and TX. These are  the only connections on the GPIO header.

Booting appears normal and I can log on to the PI. Voltage on the meter seems stable at 3.3V. When I try to shut it down either by pushing the button again or issuing "gpio -g mode 4 out" the PI shuts down but the wittypi still holds the power.

The voltage on TX line seems to fluctuate a little during shutdown but settles down at 45mV (not zero)

I do not have an oscilloscope so I can not see if the TX is noisy. I have used TX/RX as console login earlier so they are functional but not attached  now.

I have also replaced the PI with another one of the same model:  "Raspberry Pi Zero W Rev 1.1"

The behavior is exactly the same. System shutdown but no power cut.

My system environment is:

Distributor ID: Raspbian
Description: Raspbian GNU/Linux 11 (bullseye)
Release: 11
Codename: bullseye

Linux raspberrypi 6.1.21+ #1642 Mon Apr 3 17:19:14 BST 2023 armv6l GNU/Linux

I have a few more thoughts that I would like to share with you. After a brief look at the attiny processor's firmware on your github I saw that there is a mechanism that cuts power after a long press of the button. I tried it and it works fine.

It is not necessary to disconnect/reconnect power to get it back in a working state.

There is apparently a working powercut mechanism in the firmware. The problem with my wittypi is that it is not triggered by The TXD line going low. I believe that the 45-50mV level that was observed should be interpreted by the attiny processor as a logic low. The most likely explanation I can think of is that the input pin on the attiny that senses TXD is broken/disconnected.

Just some thoughts on a Saturday afternoon.

It is expected behavior, that the voltage on TXD (Vtxd) drops to near zero after Raspberry Pi has been shut down. This is how Witty Pi's firmware knows the Pi is off and then cut the power.

When Raspberry Pi gets powered and boot, Vtxd should go to about 3.3V within a few seconds. Vtxd will go through an diode and also be smoothed by capacitor before feeding to ADC in ATtiny841. If the serial port is in used, Vtxd may be pulled down from time to time, but the voltage seen by ADC is stable and the firmware knows the Pi is still on. After the Pi gets shut down, the Vtxd should go to near 0V within a few seconds, the firmware knows the Pi is off and will cut the power.

45-50mV is so low voltage and it will be interpreted as logic low, which is expected.

Since your TXD behaves normally, there is another possibility, that the SYS_UP signal did not arrive to Witty Pi's MCU and hence the power cut logic will not be triggered. When the SYS_UP signal (from GPIO-17, BCM naming) arrives the MCU, you will see the white LED on Witty Pi very quickly brinks once or twice (depends on the software version). If you don't see this quick brink(s), most probably GPIO-17 is not well connected.

Thanks for the clarification about the connection between TXD and the Attiny.

I had an old PI2 lying around so decided to move the Wittypi there and install the same software as my two PI Zeroes are running. Everything worked!! 

I will be away from home for a few days now. When I get back I will move the Wittypi back to the PI Zero and investigate  further around SYS_UP/GPIO17 as described. It is strange that both my PI Zeroes do not cut power properly.

I will report back my findings.

I have moved back to the PiZero now and I have made some new observations. This powercut  problem has  to do with shutdown in the afterStartup script. When I run with an empty script I can do  shutdown/powercut wiithout problems either by pressing the button or issuing "/usr/bin/bash -c 'cd /home/pi/wittypi; . gpio-util.sh; gpio -g mode 4 out '" on the command line.

I have written a very simple afterStartup script that  sleeps for 10 seconds and then tries to shut down.

. /home/pi/wittypi/gpio-util.sh

/usr/bin/sleep 10
gpio -g mode 4 out
# gpio -g write 4 0 # optional
exit 0

When this script is run on boot it will shutdown the PI but will not cut power. I have not used gpio-util before. I think wiringPI was used earlier but it is now obsolete and not included in the newest OS release

When I run with an empty afterStartup script  I can see the two blinks that was described in an earlier post. With the script as  above there are also two blinks but the white led seems to stay on longer immediately after.

As far as I can see the system runs the script in background so I am probably not blocking anything.

I don't think the afterStartup script you provided can shutdown your Pi after boot.

The afterStartup script is run before the SYS_UP signal gets sent, and it also happen before the daemon.sh start to listen to GPIO-4: https://github.com/uugear/Witty-Pi-4/blob/main/Software/wittypi/daemon.sh#L174C58-L174C58

Your afterStartup script is blocking (because no '&' at the end of command) and everything after it can not run until afterStartup.sh quits.

Your afterStartup script pulls down the GPIO-4 while the daemon.sh has not started to listen to GPIO-4 yet, hence no shutdown should be initiated.

If you directly run the shutdown command in afterStartup script, then it can shutdown the Pi for real, but the SYS_UP signal has not been sent out yet and Witty Pi's firmware will not perform the power cut logic.

It is recommeded to put your script content in a separated script file and run that script file in afterStartup script, by appending '&' at the end of that command line you don't block the daemon.sh script.

I  have also come to the same conclusion and have already modified the code as described. Works perfectly. I wondered why the example code  I had written works on a wittypi 3. After a quick look at the daemon for that version I  saw that the sequence of operations are different. Besides,  the afterStartup script is started in background so there are no blocking issues.

I think the problem is solved now. It really boils down to a small software migration issue between the wittypi4 and earlier versions. Thanks for your assistance.

After having solved the shutdown problem I am moving on to migrate my wildcard startups
Between 17 and 18 I started wittyPi.sh and selected the example "turn_on_every_hour.wpi" as schedule script
I got the message that next startup would be at 19:00:00 and turned it off with the button.

At 19:00:00 nothing happened. No startup. The clock seemed to be correct earlier today.
Waited 5 minutes and tried to start with the button. It would not start. Seemed to be locked.
When the button is pressed there is a short blink in the red led. The white led was blinking steadily as usual.

Disconnected and reconnected power. White led blinking. Still would not start.
Removed the wittypi and booted the PiZero standalone.. It booted.
Is the wittypi broken now ?

@terrafox it is a known issue that the MCU gets reset when you tap the button. Usually it has something to do with the power supply.

There is a topic about this issue: https://www.uugear.com/forums/technial-support-discussion/witty-pi-4-tapping-the-on-off-switch-doesnt-turn-on-the-raspberry-pi/

The workaround mentioned in that topic has been proved to work.

10 uF electrolytic capacitor soldered in place and we are back in business. Thanks for the tip. Testing can continue..

I probably have an old version purchased from one of your distributors. Is there an easy way to visually identify the hardware revision of these boards ?

I have now been running on an hourly schedule (turn_on_every_hour.wpi) for a couple of days.

Works perfectly. I have one last question.

Here is a fragment of wittipy.log:

[xxxx-xx-xx xx:xx:xx] Witty Pi daemon (v4.13) is started.
[xxxx-xx-xx xx:xx:xx] Running on Raspberry Pi Zero W Rev 1.1
[xxxx-xx-xx xx:xx:xx] Seems RTC has good time, write RTC time into system
[xxxx-xx-xx xx:xx:xx] Writing RTC time to system...
[2023-10-14 23:00:41] Done 🙂
[2023-10-14 23:00:41] Firmware ID: 0x36
[2023-10-14 23:00:41] Firmware Revison: 0x03
[2023-10-14 23:00:41] Current Vout=5.28V, Iout=0.08A
[2023-10-14 23:00:42] System starts up because scheduled startup is due.
auto run enabled
Logfile : 20231014_230049.log
[2023-10-14 23:00:49] Send out the SYS_UP signal via GPIO-17 pin.
[2023-10-14 23:00:50] Pending for incoming shutdown command...
[2023-10-14 23:00:53] Skip scheduling next shutdown, which should be done externally.
[2023-10-14 23:00:53] Schedule next startup at: 2023-10-15 00:00:00
[2023-10-14 23:01:06] Unknown/incorrect shutdown reason: 0x01
[2023-10-14 23:01:06] Halting all processes and then shutdown Raspberry Pi...

I claims that the shutdown reason is unknown/incorrect.

I would have expected something like "Shutting down system because button is clicked or GPIO-$HALT_PIN is pulled down."

According to the implementation, the shutdown reason is taken from an I2C register (I2C_ACTION_REASON), whose value is set by the firmware. If you tap the button to shutdown, or the scheduled shutdown is due, the firmware knows it and will update this register.

If you shutdown the system directly with shutdown command, the firmware doesn't know about it and the register is not updated. The reason value 0x01 is still the reason for previous startup (REASON_ALARM1).