I've now written one very trivial PIO program so I feel qualified to help you debug this.
I don't see any obvious issues with the way you have your PIO set up. One thing you might have considered: did you ever think of trying to check whether the pico is actually emitting the values you think it is on the pins you think it is (e.g. with a multimeter or some LEDs)? The reason I ask is that the problem could be somewhere else in the system.
One other fun idea: consider shrinking the shift register to size 6, and fetch each row one by one. With delays or breakpoints in between each row, it will be easy for you to read the measurement tools and verify whether the PIO program is outputting what you think, and whether the rest of the system is inputting what you think. I guess you'd have to output each row four times to saturate the buffer and cause the program to stall, but it would still work.
Also consider drastically slowing down the clock to watch the behavior in slow motion. The clock divider has sixteen bits. Use them all! You can slow the PIO clock down to 125MHz/65535=1.90737774kHz. From there, you can actually disable and enable the state machine between each SM tick to give yourself more time to look at things.
These approaches could greatly narrow down the source of the problem. Just a thought!![:)]( "Smile")
There is also this debuggin code. It's kind of a pain to get working with GDB but you can look at my half-finished PIO program for some inspiration. You can call StepPios() with a watchpoint on . . . I didn't actually extract much useful information from this but it seems like a useful tool for more complicated problems.
I don't see any obvious issues with the way you have your PIO set up. One thing you might have considered: did you ever think of trying to check whether the pico is actually emitting the values you think it is on the pins you think it is (e.g. with a multimeter or some LEDs)? The reason I ask is that the problem could be somewhere else in the system.
One other fun idea: consider shrinking the shift register to size 6, and fetch each row one by one. With delays or breakpoints in between each row, it will be easy for you to read the measurement tools and verify whether the PIO program is outputting what you think, and whether the rest of the system is inputting what you think. I guess you'd have to output each row four times to saturate the buffer and cause the program to stall, but it would still work.
Also consider drastically slowing down the clock to watch the behavior in slow motion. The clock divider has sixteen bits. Use them all! You can slow the PIO clock down to 125MHz/65535=1.90737774kHz. From there, you can actually disable and enable the state machine between each SM tick to give yourself more time to look at things.
These approaches could greatly narrow down the source of the problem. Just a thought!
There is also this debuggin code. It's kind of a pain to get working with GDB but you can look at my half-finished PIO program for some inspiration. You can call StepPios() with a watchpoint on
Code:
(PIOStateSnapshot *)&g_PIOStateBuffer[g_PIOStateBufferOffset-GetPIODumpSize(mask)]Statistics: Posted by jags84 — Wed Apr 03, 2024 4:36 am