I’m currently trying to access the P9-pins which are part of the simple default cape-design. These are part of the FPGA-design and located in CAPE/P9_GPIO_0. I put in identify as the on-chip debugger to see the transfers as I do not get the data written into the GPIO-core.
What I do is:
sudo devmem2 0x41200000 h a
trigger for the APB_BIF_sel-signal in identify
What I see is that the second slave is selected (CoreAPB3_CAPE_0_APBmslave2_PSELx going to 1), however the PWRITE-signal is staying at 0. The data-value would be present on PWDATA, however as the PWRITE-signal is not asserted, nothing changes.
Hello @moadl,
I haven’t used devmem2. I just looked at its code and it’s similar to my blinky.c program that can write/read the CAPE over APB.
It’s strange that you see pselx but you don’t see pwrite. From the devmem2.c code I just looked at, it does a read followed by a write. I suspect Identify is triggering on the read and missing the following write. Can you change your trigger from pselx to pwrite?
Other thoughts:
Can you change access type from ‘h’ to ‘w’? It shouldn’t make a difference but the APB bus is 32-bits.
Can you provide the url to your gitlab repo? I can poke around with Libero to see what we can see.
Can you download the artifacts from my repo and compile/run the blinky.c program (in the top directory of repo), to check if identify sees pwrite?
Here is my repo and a youtube video of how I did it.
the issue was actually exctly the topic that BustedWing suggested, having triggered incorrectly. devmem2 seems to do some reads before it does any writes and my buffer was just a small one. When triggering on the pwrite I see that write-commands.
Thanks for the mental nudge. ;o)