DPIPixels on Pi Zero 2

[ElfStuart]

Hi

After some assistance...

I have created a new 24ch cape that is using the new DPI driver on a reaspberry PI zero 2 running bullseye as it's brain (have also tried SD card in a pi 4 with similar results) running latest current master branch code as of today.  It is using SN74AHC245N chips (concious they react slightly faster than the SN74HC245N's that I have seen people using so wonder if that could be a contributing fact to my error?)

My GPIO config is as follows:

"outputs": [
        {  "pin": "P1-7" },
        {  "pin": "P1-11" },
        {  "pin": "P1-13" },
        {  "pin": "P1-15" },
        {  "pin": "P1-19" },
        {  "pin": "P1-21" },
        {  "pin": "P1-23" },
        {  "pin": "P1-29" },
        {  "pin": "P1-37" },
        {  "pin": "P1-35" },
        {  "pin": "P1-33" },
        {  "pin": "P1-31" },
        {  "pin": "P1-40" },
        {  "pin": "P1-38" },
        {  "pin": "P1-36" },
        {  "pin": "P1-32" },
        {  "pin": "P1-26" },
        {  "pin": "P1-24" },
        {  "pin": "P1-22" },
        {  "pin": "P1-18" },
        {  "pin": "P1-16" },
        {  "pin": "P1-12" },
        {  "pin": "P1-10" },
        {  "pin": "P1-8" }
    ]

when running a simple RGB chase test from fpp the string outputs are misbehaving in 2 different failure modes depending on the port, ...which I think are both timing related.

Issue 1 - the string chases RGB correctly apart from the first pixel in the string which only comes on blue and is off when it should be red or green

Issue 2 - the string chases blue,yellow, off (and occasionaly has a red flicker)

Here is the alignment of port to issue:

   

port #	pixel count	issue type
port 1	50	issue 1
port 2	50	issue 1
port 3	400	issue 1
port 4	472	issue 1
port 5	50	issue 1
port 6	50	issue 1	plus lots of flickering
port 7	50	issue 1
port 8	100	issue 2
port 9	100	issue 1
port 10	100	issue 2
port 11	100	issue 2	plus flickering - might be solder related
port 12	100	issue 2
port 13	50	issue 2
port 14	200	issue 2
port 15	375	issue 1
port 16	375	issue 2
port 17	129	issue 2
port 18	129	issue 2	plus flickering - might be solder related
port 19	150	issue 1
port 20	150	issue 2
port 21	50	issue 2
port 22	50	issue 2
port 23	70	issue 2
port 24	70	issue 2

This is a prototype board so would expect the odd dodgy solder joint but the pattern of the issue suggests it more down to config than hardware

my /boot/dpipixels.txt looks like (is this correct as I have been testing for a few months and might have something hanging over in this):

#####################################################################
# DPI Pixels framebuffer config
# https://www.raspberrypi.com/documentation/computers/config_txt.html
#
# Date Added: Sun 27 Mar 2022 06:42:47 AM BST
######################################################################
# Enable DPI
enable_dpi_lcd=1
#
# Set group/mode to allow custom resolution and timing
dpi_group=2
dpi_mode=87
#
# RGB24 888, RGB color order
dpi_output_format=0x17
#
# Enable DPI framebuffer on < Pi 4
max_framebuffers=2
#
# Make onboard HDMI fb0 and DPI fb1 if HDMI is in use, otherwise DPI is fb0
framebuffer_priority=2
#
# Force HDMI on (as fb0) so DPI becomes fb1
hdmi_force_hotplug=1
#
# Custom resolution with 40 FPS timing
dpi_timings=362 0 0 1 0  162 0 1 1 1  0 0 0  40 0 2400000 1
#
# Enable UART2 on Pi 4 since UART0 TXD pin is used by DPI
dtoverlay=uart2
#
# Disable SPI
dtparam=spi=off

Is there a parameter I can tweak somwhere to test timings?

Thoughts anyone?

[CaptainMurdoch]

The dpipixels.txt file would be updated at a reboot if the timings line needed updating.  This file hasn't changed much until recently when I fixed the timings line for the Pi 4.  I just pushed this fix on Thursday, can you confirm what exact version you are running to make sure you have that fix?  I haven't seen the issue #1 you are referring to and I have the DPIPixels code running on about 6 systems including Pi 4B, 3B, 2B, and 1B.

Have you tried connecting the first pixel directly to the GPIO pin and seeing if the issue goes away?  That would tell you whether it is the cape or not.  At a short distance, the 3.3V signal coming off the Pi should be good enough to drive the first pixel, we have lots of users driving pixels directly off the Pi without any cape, I do it myself for a small infinity mirror in my office.

[ElfStuart]

Cheers Chris

Sorted the issue - wasn't a config or PCB design issue

Was my fault - I accidently loaded the board with SN74AHC245N buffer chips rather than the lower input voltage version SN74AHCT245N - that pesky missing 'T' in the model number causing the issue.

Now have 24 channels all prefectly behaving

[CaptainMurdoch]

Thanks for reporting back.