[Solved] Witty Pi 3 mini - does not turn on

Witty Pi's firmware hasn't implemented such kind of power cut.

I doubt there was peak current draw and your power supply could not deliver that much current. 

Have you tried with different power supply?

Is the glitch has stable 40 seconds interval?

As I said, I checked the Power Supply, I also tried different Supplies. 🙃 

I got the time to measure some signals on the oscilloscope (see Attachment):

 M1.bmp

Channel 1: 5V Supply of Raspi (pin 2  on pinheader)
Channel 2: 5V of Power Input (on C2 of witty pi)
No voltage drop on power input side (the small glitch at power return is probably due to my long GND wires of the probes)

 M2.bmp &  M2.bmp

Like M1 but longer time span. The glitch happens every 38.8s ... I would estimate at least within +/-1s .. so pretty stable?

 M4.bmp

Channel 1: 5V Supply of the  Raspi like before
Channel 2: 3V3 Supply of the Witty Pi (Measured on P3 Header)
-> Also no Voltage Drop here before/during the glitch

 M5.bmp

Channel 1: 5V Supply of the  Raspi like before
Channel 2: Pin6 (PA7) of the ATiny841, which I think switches the Dual Mosfet and the Power to the Raspi
-> Signal is definetly going Low, so it seems much like a digital issue here??

I have to admit, it really looks like this is happening everytime on the same position in the boot process, so sharp current draw is not unlikely.
However, I could not verify it on the Power Supplies and the same power supplies do work happily without the witty pi.
As I said I am pretty much clueless why this would happen .. so I am Happy for all suggestions. 😥

During measurement today, it started again to work as expected for some time. But not for long.
In my Setup i am also applying a battery voltage (12V) to VIN, but there is no LDO but an external DC/DC for the 5V.
However the glitch also happens only with 5V Supply through USB port.
I also presumed some HW issues, like a cold solder joint, but resoldering some parts did not help. --> I ordered another Witty Pi 3 mini, just in case. 

Are there any other conditions the ATiny would pull PA7 low?
Maybe the ATiny is doing an unintended Reset? Could we check this somehow?
Could it have something to do with the current Sensing?

Regards,
Oskar

@oskarw controlling the mosfet with fixed interval, the first thing comes to my mind is the dummy load. However dummy load only works when the Pi is in sleep, also the dummy load interval should be much shorter than 38 seconds.

You ordered another Witty Pi 3 Mini, so you have two of them now? Do both of them have the same behavior?

I think I have found the issue. It seems the ATiny gets an unintended Reset, probably due to EMC interference.
I am using a Raspi Zero W with an RPi Cam in close proximity, and during Booting i have found that there is a Spike on the Reset of the Atiny.

 Reset_Voltage.bmp

CH1: Voltage at RESET pin of the ATiny
CH2: Voltage at the Raspi

Looking closer, I did not found any ciruitry on the Reset Pin!! 😳  No ext. Pull-Up, no blocking capacitor close to the pin. 😵 
No Wonder the device gets reset on any noise picked up by the little reset antenna ... it also explains why the system sometimes booted through.

After placing an 10k PullUp and a 4.7nF to GND, the issue seems to be gone the 3V spike and noise got reduced to ~80mV.
Up to now the System seems to run stable.

The other boards I ordered did not yet arrive. Therefore I have not tested them and probably will not do as the issue is gone.
Assuming they have the same Hardware Revision, I would assume that they show the same problems.

@oskarw thanks for sharing the information.

According to ATtiny841's datasheet, as shown in Figure 8-1, the reset pin has its own internal pull-up resistor and spike filter. Also Table 25-5 shows the threshold voltage of reset pin is 0.2Vcc, which is 0.66V. It is surprising to see it actually reset the MCU.

Please see the attached picture, which reversion is your Witty Pi 4 Mini?

Posted by: @admin

↑

According to ATtiny841's datasheet, as shown in Figure 8-1, the reset pin has its own internal pull-up resistor and spike filter. Also Table 25-5 shows the threshold voltage of reset pin is 0.2Vcc, which is 0.66V. It is surprising to see it actually reset the MCU.

 

Yes, in my Measurements, the voltage only drops to ~1V, but the same table only gives 700ns pulse width for the reset and my personal measurement equipment is not suitable for HF.
Therefore I think it is quite possible that the spike in my measurement can trigger a reset.

Besides the footnote on the table says "Values are guidelines only" ... whatever that means.

As an Electronics Hardware Engineer, I would consider external pull-up and capacitance on the RESET as a standard circuitry for EMC-Robustness of embedded Systems.

Also Microchip/Atmel do recommend it. (See Chapter 4.9.2 of App-Note AVR040: EMC Design Considerations )
They even recommend and addtional diode to VCC ... probably for extra ESD protection.

Posted by: @admin

↑

Please see the attached picture, which reversion is your Witty Pi 4 Mini?

As stated in the Title I am using a "Witty Pi 3 mini" .. so none of the Revisions above.

@oskarw Thank you for the insight. Witty Pi 4 Mini has similar issue, we added a decouple capacitor to 3.3V rails and that does help. Maybe adding protection to RST will help further.

Not sure if it's the same issue, but lately (last week) after updating the system, my Witty Pi 3 Mini pretty much stopped working completely with Pi Zero 2 W.

On scheduled startup, it went through the boot and then immediately turned off.

I tried a fresh install of Raspbian OS LITE 2024-03-15, 2023-12-11 (both bookworm based) and an ancient 2022-09-26 (bullseye based) where I am 100% certain it used to work fine in the past. So, on a clean system, without any updates, I downloaded install.sh and installed wittyPi software, cleared all settings and applied a shutdown schedule - it doesn't turn off, and there's nothing interesting in wittyPi.log (just "Setting shutdown time..." and "Done : - )".

Then it sometimes boots up and turns off by itself but I didn't observe it consistently until now to be able to give any more details.

Either way, at the moment the device is not working at all and I can't make it work with the older versions of the OS either, which leads me to believe that it's the fault of one of the packages installed by the install.sh script: i2c-tools, libi2c0, and/or read-edid, assuming it's updating the repositiories when doing that.

Please let me know if I should make this into a separate issue, thanks.