Pi Pico with P5 panels "crashing" the displays

[DoomHammer]

Recently I've observed this behavior on P5 panels, but I think I've seen this before with others as well.

The thing can manifest itself either earlier or later and I haven't found any rule to why this happens.

Basically, after some time of scrolling various images (either text or bitmaps) the display stays stuck on some rectangular patterns and doesn't update any further.

Here are some examples of the crashed displays:

What might be the reason for this behavior and how can we remedy it?

[board707]

Recently I've observed this behavior on P5 panels,

Hi!
The letters "P5" just means a pitch in millimeters between leds and says nothing about panel itself/ Please clarify your setup - what is the panel dimensions in the pixels and how much the panels in set. What is the panel driver chip?

What might be the reason for this behavior

Could you please show the code that produce this result?

[DoomHammer]

These particular panels are P5 64x32 using SMD2121 RGB LEDs and IC: 16207 / ICN2038S with 1/16 scan.

I will create a minimalist example to share.

One observation is that it might occur quicker/more often when the flash is being read frequently.

[board707]

Is the other code in PiPico still running after display stucks?

[DoomHammer]

This is also a great question, I haven't checked that yet. So a minimal example that should induce the crash and also logs to Serial from time to time?

[board707]

It would help, I think.
I believe that there was another user with similar problem... Finally he wrote, that the issue was solved, but I don't remember the details. I will try to find his messages, it could be an useful info.

[board707]

Addition
I found correspondence with the guy whose panels were freezing on pico. But it seems that this is not the case.
He writes that in the end he just replaced the Pi Pico board and everything was fixed

[DoomHammer]

What were the symptomps, though?

[board707]

The image on panels freezes after a few hours of work. It seems to be a bad soldering on the plate.

[DoomHammer]

Still trying to get a minimal easy reproduction. So far I've noticed that single panel seems less prone to this crash than chained panels.

[DoomHammer]

And yes, after the display crashes the serial messages still go on.

[DoomHammer]

OK. I got it.

https://github.com/DoomHammer/dmd-crash

This with two 64x64 panels crashes the screen within several seconds (and later still posts Serial messages).

[DoomHammer]

Tried that with a single panel and it seems to be crashing as well.

[board707]

Thank you, I will test it and see what I can do with it.

[board707]

Hi
What library version do you use with this test code?

[DoomHammer]

1.1.2

[board707]

The base class of DMD_RGB is the DMD_RGB_BASE2, not the DMD_RGB_BASE. Using the DMD_RGB_BASE can lead to unpredictable results.

[DoomHammer]

And we have unpredictable results 😅

Why is it so, though?

[DoomHammer]

Same results with DMD_RGB_BASE2<4>

[board707]

Thank you for the info.
It will take a 2-3 days for test this.

[board707]

Hi
I see the problem and figured out how it happened. In some cases, a new data transfer to the matrix starts earlier than the previous one ended. However, I don't understand at all why this happens.
For now I can only suggest a workaround for this. I didn't test it for very long, but in my tests it never froze.

To the file DMD_RGB.cpp in the method DMD_RGB_BASE::scan_dmd_p1()you need to add a line:

dma_channel_wait_for_finish_blocking(dma_chan);

just before the lines :

dmd_out_program_reinit(pio, sm_data, data_prog_offs, &pio_config);
dma_channel_set_read_addr(dma_chan, buffptr, true);

(these are lines 290-291 according to the latest version of the library).

Let me know if this solves the problem.

[DoomHammer]

It definitely works better now. I will test on some other workloads as well.

Should I create a PR with this?

[board707]

It is up to you. If not, I will add this in the next commit (if your tests confirm that it works, of course).

[DoomHammer]

BTW: any ideas why this seems to be more pronounced when there's a lot of flash reading?

[board707]

Thank you, PR merged.

[board707]

Fixed in 6916082