01-23-2019 05:46 PM
Dear Forum Members,
We are having a problem when changing resolutions going into our VDMA. When we start, we configure for 1080p by default. We can change sources via the AXI Stream and everything works fine as long as the resolution does not change.
When the resolution feeding the VDMA changes, we reconfigure the VDMA and the system may or may not work the first time. Subsequent changes of resolutions will certainly fail.
Incidentally, we are using the same functions to configure the VDMA for each resolution, including the initial configuration.
From what we can tell, we believe the S2MM buffer pointers are showing the input buffers filling up and alternating between two buffer locations but buffer pointers on the MM2S seems to be stuck on one buffer and don't change.
My guess, is that we are not clearing a FIFO someplace when resetting the VDMA. Or, maybe we are not waiting for some flag before we enable the new VDMA configuration. It ALWAYS works when we first reset the system so we know the problem is in reconfiguring the VDMA for the new resolution stream.
One more thing: We are using the API for all our configurations.
Has anyone experienced this behavior before? Any suggestions?
(I included a modified main.c file with most relavent code.)
01-24-2019 12:04 PM
Okay, it gets more interesting...
When I switch from 1080p to 480p everything works just fine. Switching back works just fine. No lockups. I cannot get the system to fail if I switch between these resolutions. Same for 1080p and 1024x768 and/or 1280x1024. Never locks up. Image looks great.
The only time the problem occurs is with 720p. I can't see anything wrong with timing within the VTG. The timing matches the CEA-861-E standard and I haven't modified anything with timing in the API code.
Any ideas what might be going on?
01-25-2019 12:20 AM
Did you check the status registers of the VDMA to see if you were getting any error? It might lead to the root cause
01-28-2019 01:44 PM
Thank you for your assistance resolving this problem.
Attached you will find three files: ConsoleDump3.txt, VDMARegs3.JPG, and memorytest.c. VDMARegs3.JPG shows the registers just after the crash.
We powered up our system and switched in a 1080p signal to our FPGA. This signal is encoded on a Aurora bus and arrives at this FPGA where it is decoded via AXI4-stream as a front end to our VDMA. We have a RTL block which reads encoded data within the blanking period to indicate the Hactive and Vactive sizes. From the VDMA the data goes to a AXI4-Stream to Video Out block. In parallel, we are using a Video Timing Generator to establish new timing parameters for the data stream and combines the newly created H, V, and DE with the parallel video bus to an external HDMI transmitter.
Generally, everything works well. Any time we need to reconfigure the VDMA things become unstable. In this example, we go from 1080p to 720p then back again to 1080p. In this case, the VDMA crashes when going from 720p to 1080p. Often, the system crashes earlier, simply crashing when going from 1080p to 720p alone.
"Crash" is defined like this: We don't get an output. The input side (S2MM) seems to remaining working just fine. We can tell this by seeing the buffer pointer/indicators toggle between our three frame buffers. However, the output side (MM2S) crashes hard so only a reset or reload of FPGA code will free up the system. We are unable to reset the VDMA output side. When the crash happens, more often than not, we still see the Microblaze system operating just fine.
For the source code, we modified "memorytest.c" for our test system. We created a polling routine to watch for a change in the video stream. "new_res_flag" indicates when a new video stream is detected.
Thank you for your help!
01-29-2019 10:13 AM
When we redefine the VTG to generate new timing signals, everything seems to work well.
However, when we change the VDMA, this is where we see everything hang.
Our process goes like this:
(a) Shut down the flow of data coming into the VDMA
(b) Shop the VTG Generator using
(c) Stop VDMA using "DmaStop" for read and write.
(d) Reconfigure the VTG and VDMA
(e) Restart VTG using "EnableGenerator"
(d) Restart VDMA using "DmaStart" for read and write.
(e) Restart the flow of data into the VDMA read buffer
I never get error messages returning from these stop and start functions. Always, XST_SUCCESS.
01-30-2019 01:11 AM
Looking at you register values, the writting side seems to be wrong.
If you check the value @0x34, the register value is 0x11910.
This means that you have a VDMA Internal Error and End of Line Early Error for the S2MM interface (Stream to Memory Map -> wrinting interface). Probably becasue you have a mismatch between the resolution you are inputing to the VDMA and the VDMA configuration
01-31-2019 02:06 PM
We have noticed these error messages too. It only seems to happen when we start up the VDMA. They are not persistent, from what we can see. The reason you see this message now is that the system crashed before we could receive the error interrupt and clear the flag.
Sometimes, the lockup happens when we go from a 1080p source to 720p source and other times, if we boot up the system with the 720p source the lockup happens when we transition from 720p to 1080p.
We feel we have been following the "Programming Sequence" as defined in pg020_axi_vdma.pdf. We have also tried to stop the DMA and VTG then restart them after the new data has been written. Neither method solves the lock up problem.
01-31-2019 02:12 PM
Interesting, within our Microblaze infinate loop, we write out the current VDMA input and output buffer pointers. Pretty interesting to watch the pointers bounce between the three buffers.
A side effect of the printf's is that now switching between sources no longer locks up the system. I can go from 1080p to 720p then back to 1080p without any issue or lockup. Frankly, I can not lock up the VDMA no matter how many times I switch. Not sure why this delay is resolving this problem and I don't know if the problem will go away when I am not in the SDK Debug mode.
Do you have any idea what is happening?
02-04-2019 03:48 AM
So you are using the VDMA in Park mode? Could you explain your full system? How do you configure the VDMA? How do you decide to change the frame pointer?