STM32: 32x32 RGB Matrix experiences flickering, stretching

[hierophect]

Using the 32x32 matrix with an STM32F405 Feather Express, I'm observing a number of flickering and misplaced LEDs, which distort the edges of the image. This appears to occur more on one side of the matrix than the other.

Test script. This exact same script, when used on a Feather M4 Express with the same matrix (jumpers still used and only connections re-arranged) does not cause this issue.

This behavior also with Circuitpython built at the original STM32 RGBMatrix PR (#2831), so it may be specific to this screen size, since @jepler did not report any problems like this in his PR.

Any additional testing to confirm this issue would be appreciated! I've checked it with two separate feathers and two separate LED Matrixes of this size, but I do not have any other sizes to check against.

Sorry for lousy image quality, my phone camera really isn't catching this issue well. The "wrong" pixels are a lot more apparent to the naked eye. Attempted text is "++++"

[tannewt]

@jepler Thoughts on this?

[ladyada]

@hierophect please post a video, it isnt clear to me what you're referring to

[hierophect]

@ladyada

[ladyada]

this looks like a power or voltage issue. make sure the panel power supply is 5V or less

[hierophect]

this looks like a power or voltage issue. make sure the panel power supply is 5V or less

That was my first thought too, or a connection issue, but I've found in testing that the exact same setup works fine (jumpers, cable, featherwing, everything, only the feathers & connection positions swapped) on the Feather M4 express and only gives this bad performance on the F405. It's using the 5V, 4A power supply listed on Adafruit.

[hierophect]

Maybe a clock issue?

[ladyada]

hmm may be its too fast

[tannewt]

We should check this soon because we have new RGB Matrix projects in the pipeline.

[hierophect]

I was going to test this after my new timer tech is in, since I just changed the internals of Protomatter anyway.

[hierophect]

Returning to this issue, notes so far after using a Saleae to capture the signal differences between the STM32F405 Express and the M4 Express. Test sketch: https://gist.github.com/hierophect/a8c75eed9725b4e2a3683a9ead61c5f7. I observed LAT, OE, A, B, R1, R2, and CLK. @PaintYourDragon and @jepler, here are my findings so far:

• ST frequencies on the A and B lines were over twice as fast as the SAMD. I cut them in half by doubling _PM_timerFreq to 84000000 but they still don't match up exactly (B is 940Hz on ST compared to 884Hz on SAMD). This didn't appear to have much effect on the image quality.
• On the SAMD, before any information is sent out on the R1 line, I can observe there's what seems to be a synchronized pulse before all the lines become active that includes the CLK line. I don't see that on ST (CLK never goes high, ever).
• In the guide page for the SAMD, OE and LAT are listed as being on pins D1 and D0 in the code, respectively, but on the diagram and the feather schematic, they are flipped (D0 and D1). I assume the code is the correct version since it works. I tried flipping them on the ST version - this improved resolution but only on half the image.
• The actual ST pulses on the R1 line seem kind of frayed compared to SAMD (see below).

Otherwise, the two signals are very similar. For my test sketch, both deliver about 8ms of data on R1 when the sketch starts. Only LAT, OE, A and B are active from that point on.

@ladyada mentioned it might be #define _PM_ROW_DELAY 8 that is incorrect - I'm actually not sure, looking at the signal, where this value actually plays in? I don't see any delays that are that long during what seems to be the relevant period of data transfer.

[hierophect]

I should amend the above to say I'm getting completely different data from R1 out of my saleae now, so I'm suspecting a hardware error on that, if one that frustratingly was exactly the same across both the SAMD and ST across two trials, apparently.

[hierophect]

I think this might need to be tackled by someone with an oscilloscope.

[hierophect]

After having discussed things with @jepler, it seems like the root of this issue was the aforementioned documentation mixup in the guide page, where the fritzing pinout of the Feather M4 Express had the LAT and OE pins swapped.

The actual code and layout of the Featherwing were both correct, so this caused no issues when an actual M4 was used, but by attempting to connect a STM32 Feather to the featherwing using cables, these two pins were swapped and caused the original issue. The other instability I had seems to have just been general cable noise - removing the feather and adding jumpers directly from the matrix to the feather seems to have resolved the issue.

While the address line frequencies on the STM32 is still 2x as fast as the Feather M4, these don't seem to impact image quality, nor does _PM_ROW_DELAY. The protomatter crash (resolved in #3441) also seems unrelated to this problem.

Since the update to the guide diagram is not a git-related fix, I'm closing this issue.