MatrixPortal: deep sleep messes with HUB75 Matrix

[flavio-fernandes]

This is possibly not a MatrixPortal, but a Circuit Python issue that affects the Matrix Portal. Nevertheless, let me start here and see how the feedback on fixing this issue goes.

While doing a basic test with Matrix Portal, I have a code that does this:

from alarm.time import TimeAlarm
from alarm import exit_and_deep_sleep_until_alarms
...

def draw_a_blank():
    bg_color_palette = displayio.Palette(1)
    bg_color_palette[0] = 0
    bg_color_palette.make_opaque(0)
    bg_color_bitmap = displayio.Bitmap(display.width, display.height, 1)
    bg_sprite = displayio.TileGrid(
        bg_color_bitmap, pixel_shader=bg_color_palette, x=0, y=0
    )
    splash.append(bg_sprite)

def go_to_sleep():
    draw_a_blank()
    # up to here life is good, and display is all 'blank'
    print("zzz")
    time_alarm = TimeAlarm(monotonic_time=time.monotonic() + DEEP_SLEEP_INTERVAL)
    exit_and_deep_sleep_until_alarms(time_alarm)
    # at this point, screen looks like the image shown in this issue

go_to_sleep()

In an ideal world, the deep sleep should have not messed with the blank screen.

[flavio-fernandes]

[flavio-fernandes]

@dhalbert @makermelissa what do you think is causing this? Is there a work around for a deep sleep where HUB75 is not disturbed?

Thanks,

-- flaviof

[flavio-fernandes]

Adafruit CircuitPython 7.2.5 on 2022-04-06; Adafruit Matrix Portal M4 with samd51j19
Board ID:matrixportal_m4

[dhalbert]

During deep sleep, we usually make the pins float, because that's usually the least power consumption. But we could pull down the matrix pins instead. O the ESP32-S2, we enable a pull-up, because that's actually less current.

Or is there some way to just disable the display completely?

[makermelissa]

The MatrixPortal uses a SAMD51. @jepler any ideas?

[flavio-fernandes]

@jepler @makermelissa bump ;)

[jepler]

This appears to be a core bug. As a workaround, I recommend running displayio.release_displays() before the deep sleep. The matrixportal board isn't designed for sleep or low-power so addressing this more deeply is likely not a high priority for us.

[jepler]

I sort-of reproduced this with the following script on 7.3.1:

import displayio
displayio.release_displays()

import time
import rgbmatrix
import framebufferio
import board

matrix = rgbmatrix.RGBMatrix(
    width=128, bit_depth=1,
    rgb_pins=[board.MTX_R1, board.MTX_G1, board.MTX_B1, board.MTX_R2, board.MTX_G2, board.MTX_B2],
    addr_pins=[board.MTX_ADDRA, board.MTX_ADDRB, board.MTX_ADDRC, board.MTX_ADDRD],
    clock_pin=board.MTX_CLK, latch_pin=board.MTX_LAT, output_enable_pin=board.MTX_OE)
DISPLAY = framebufferio.FramebufferDisplay(matrix)
print("x")

time.sleep(1)

import alarm
DEEP_SLEEP_INTERVAL=2
time_alarm = alarm.time.TimeAlarm(monotonic_time=time.monotonic() + DEEP_SLEEP_INTERVAL)
displayio.release_displays()
alarm.exit_and_deep_sleep_until_alarms(time_alarm)

and a pair of Adafruit 64x32 displays daisy-chained. However, the behavior wasn't consistent for me.

[flavio-fernandes]

You are awesome!!! Thanks so much for reproducing it and the work around.

Unrelated question, sort of: if I have a dogwatch enabled and then started a long deep sleep… would you expect the dog to fire still?

— flaviof

On Thu, Jun 23, 2022 at 5:36 PM Jeff Epler @.***> wrote:

I sort-of reproduced this with the following script on 7.3.1:

import displayio displayio.release_displays()

import time import rgbmatrix import framebufferio import board

matrix = rgbmatrix.RGBMatrix( width=128, bit_depth=1, rgb_pins=[board.MTX_R1, board.MTX_G1, board.MTX_B1, board.MTX_R2, board.MTX_G2, board.MTX_B2], addr_pins=[board.MTX_ADDRA, board.MTX_ADDRB, board.MTX_ADDRC, board.MTX_ADDRD], clock_pin=board.MTX_CLK, latch_pin=board.MTX_LAT, output_enable_pin=board.MTX_OE) DISPLAY = framebufferio.FramebufferDisplay(matrix) print("x")

time.sleep(1)

import alarm DEEP_SLEEP_INTERVAL=2 time_alarm = alarm.time.TimeAlarm(monotonic_time=time.monotonic() + DEEP_SLEEP_INTERVAL) displayio.release_displays() alarm.exit_and_deep_sleep_until_alarms(time_alarm)

and a pair of Adafruit 64x32 displays daisy-chained. However, the behavior wasn't consistent for me.

— Reply to this email directly, view it on GitHub https://github.com/adafruit/circuitpython/issues/6523#issuecomment-1164903071, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANQIB2MMAFHHYPTWK7XMRLVQTKGJANCNFSM5ZVVQGCA . You are receiving this because you authored the thread.Message ID: @.***>

-- Sent from Gmail Mobile

[jepler]

I'm not sure how watchdog & deep sleep interact. It's sure not documented!

[flavio-fernandes]

I'm not sure how watchdog & deep sleep interact. It's sure not documented!

Interesting. It does indeed seem to trigger WatchDogMode.RESET after I call exit_and_deep_sleep_until_alarms().

I will try explicitly calling watchdog.deinit() before the deep sleep but it would be nice if that happened automatically. Do you agree @dhalbert ?

[bablokb]

Can we reopen this? I have a program which writes to a SSD1306-oled, goes to sleep for 10 seconds and then updates the display. This works sometimes for 1 cycle, sometimes for something like 10 cycles. But then it seems the display is not released properly and the screen is garbled by the REPL. This is independent of true or fake deep-sleep,

[flavio-fernandes]

Can we reopen this? I have a program which writes to a SSD1306-oled, goes to sleep for 10 seconds and then updates the display. This works sometimes for 1 cycle, sometimes for something like 10 cycles. But then it seems the display is not released properly and the screen is garbled by the REPL. This is independent of true or fake deep-sleep,

Sorry to hear you are having this problem. I would suggest you to open a new issue with all the relevant info to your setup. This issue has been fixed for the MatrixPortal described here.

Best,

-- flaviof

[bablokb]

This has never been a problem of the MatrixPortal, but for any display (at least for all my displays).