RaspberryPi 5 and BrickHAT.set_sleep_mode(power_off_delay, power_off_duration, raspberry_pi_off, bricklets_off, enable_sleep_indicator)

[yvo]

Hi List

Last summer I was asking about the set_sleep_mode of the RaspberryPi using the BrickHAT. You will find the original post here. And the solution proposed by matzeTF was perfect.

The background was, to control the shutdown of the RPi in a controlled way in combination with an Industrial-Dual-Relay Bricklets and a second power-supply of HAT and RPi using the 5V USB-connection. This combination allows a controlled shutdown of the entire system and a final cut of any power-supply of the system.

This works perfectly so far with RPi-4.

In the meantime, I switched to RPi-5 for a new edition of the entire setup. And with this switch, I am confronted with the new following effect:

• After calling the

  set_sleep_mode()

  -function, the system starts to shutdown as defined.
• But, at the end, the Industrial-Dual-Relay is not set back to default (no connection between A and SW).

As a result, the system gets blocked in the following state:

• The system of the RPi is down.
• The Industrial-Dual-Relay still provides connection between A and SW.
• The HAT and RPi gets still power.

The only solution to solve the problem is, to manually disconnecting the USB-power-supply from the HAT. After the disconnecting, everything goes and stays as it should (no connection at relay between and SW.

Unfortunately, this behavior is not observed systematically. It occurs sometimes.

While writing this post, I started the reflection, if the power_off_delay with 5.0 seconds is to optimistic and if the problem could be solved using a longer time-period for the power_off_delay.

Do you have any ideas or suggestions?

Looking forward to any hints.

Cheers. Yvo

[MatzeTF]

I guess the Industrial Dual Relay’s status LED is still blinking when everything should be powered off? In that case, the power isn’t actually shut off. I can’t test that here right now, but as a workaround, you could try to use this right before setting the HAT’s sleep mode:

tf_industrial_dual_relay_set_monoflop(n, true, 20000)

Replace n with the number of the relay that’s switching the power. This call will instruct the Industrial Relay Bricklet to switch on relay n (which it already is) and then switch it off by itself after 20 seconds, effectively killing its own power.

Adjust the time to match however long your system needs to shut down and what the HAT’s sleep time is. I chose 20 seconds, assuming that shutdown takes 10 seconds and the HAT’s sleep mode is set to 15 seconds.

[yvo]

Hi MatzeTF

Great. Thank you very much for the fast replay.

I will test it in the next days and coming back with the result,

Cheers. Yvo

[yvo]

Hi MatzeTF

It works perfectly. Thank you very much.

In my case, I use the:

IndustrialDualRelay.set_monoflop(channel, value, time)

as the very last command. Before this command, I call the HAT to power-off:

HAT.set_sleep_mode(power_off_delay, power_off_duration, raspberry_pi_off, bricklets_off, enable_sleep_indicator)

The set_monoflop is called with slightly longer delay (e.g. 1 second) than the set_sleep_mode. With this concatenation, I have a deterministic power-off of the entire system.

Looking forward to see it working in the real-world.

Cheers, Yvo

 

[yvo]

Hi MatzeTF

Mh. there is still an issue about the entire shutdown-process of the HAT. The mentioned problem above only addresses RPi-5. The RPi-4 has never shown this kind of behavior.

Some research gave me a hint, that one difference between RPi-4 and RPi-5 is the behavior of the GPIO-4.

It seems, that on RPi-5 the level on GPIO-4 stays high (3.3V). On the contrary, on RPi-4 the level on GPIO-4 changes to low (0V). And that the behavior of GPIO-4 on RPi-5 prevents the HAT from an entirely shutdown.

Question:

• What do you think? Does it make sense to you and would it make sense to go further into this topic?

Looking forward to any hints and suggestions. Many thanks in advance.

Cheers. Yvo

[borg]

Ah interesting, so the XMC somehow gets back-powered through an IO pin? Do you know why the gpio 4 is high? Does the sleep work if you force it to low before the sleep?

You should be able to put it to low with this:

sudo pinctrl 4 op dl

 

[yvo]

Hi borg

Puh, your questions are fare to deep into the technical details for my limited knowledge.

I just found some hints, that this behavior of GPIO-4 is a main difference between RPi4 and RPi5. I have the same shutdown-procedure running on many RPi4 (8 pieces) with the same setup and the same software, but not encountering this behavior.

Strange enough, even the behavior of the 8 RPi5 is not consequently the same.

I was able to get the GPIO-4 to low (0V) using the call as you mentioned. But short after the shutdown ended, the GPIO-4 goes back to high (3.3V).