cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Adventurer
Adventurer
7,837 Views
Registered: ‎10-11-2011

AXI Video DMA operation problems

Jump to solution

I'm trying to use the AXI VDMA to write a 128 x 128 byte section of memory (malloc'd and filled in software) to the AXI Stream bus.  I originally tried using the functions defined in xaxivdma.h, but although they didn't cause any errors, the VDMA did not operate as expected.  I am currently trying to do direct register writes to the core but I'm still running into problems.  I'm able to get the VDMA to run, but transfers are not happening correctly as the core's status register never indicates returning to hold after a transfer.

 

I have the VDMA hardware configured as follows:

  • MM2S and S2MM channels
  • 1 frame store
  • Enable dynamic video parameter reads
  • No external frame sync
  • No scatter gather engine
  • Data realignment engines on both channels
  • Store and forward buffers on both channels
  • Gen-lock mode off
  • Video line buffer depth 4096 on each channel
  • 32 maximum memory burst size for both channels
  • 64 memory map and stream data widths on both channels

I'm trying to keep it relatively basic since I just need to transfer one section of memory once.

 

I'm only testing the read channel right now, and I'm using page 109 of the AXI VDMA product guide as a reference for operation.  I'm writing the following values to the registers with software:

 

MM2S_PARK = 0x00000001; (also tried 0x2, 0x3, 0x0)

MM2S_DMACR = 0x00010011;

MM2S_START_ADDRESS1 = address of data start in memory

MM2S_FRMDLY_STRIDE = 0x00000080;

MM2S_HSIZE = 0x00000080;

MM2S_VSIZE = 0x00000080;

 

The control setting I chose, as I understand from the data sheet, indicates no interrupts are enabled, IRQFrameCount is 1, Frame Count En is set so the VDMA channel halts after IRQFrameCount frames, park mode is enabled, and the DMA is running.  Polling the status register shows the channel is running after writing this value (LSB 0).

 

The park register value should mean the DMA will park after 1 frame.  Frame delay and stride value indicates no delay and 128 byte stride, then 128 byte hsize and 128 line vsize.  According to page 109 of the AXI VDMA product guide, transfer should start after writing the vsize; my problem is that the VDMA doesn't ever go into hold mode as it should after the transfer.  The status register LSB stays at 0 and the control register LSB stays at 1 (indicating run mode).  Because I have Frame Count En toggled on in the control register, the core should go into hold mode after 1 frame.

 

I've run into a wall figuring this out, so I was hoping I could get some help to get this working.  I know this post is a bit jumbled so if any clarification is needed, please ask.  Thanks in advance!

 

 

 

Tags (1)
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Adventurer
Adventurer
10,295 Views
Registered: ‎10-11-2011

I ended up hooking up chipscope and found that the VDMA was in fact transferring to the downstream core (XFFT), but the XFFT was not functioning correctly (not transforming the data and outputing it) which caused the S2MM stream to never receive data from the XFFT output so the VDMA never returned to hold status.

View solution in original post

0 Kudos
7 Replies
Highlighted
Xilinx Employee
Xilinx Employee
7,827 Views
Registered: ‎08-02-2011

Can you attach your .mhs and do an XMD dump of your VDMA register space and post that as well?

 

Is this hardware or simulation? Have you thought about getting chipscope involved?

 

Are you seeing any error conditions in the status register?

 

Also, what version of the core are you using?

 

 

www.xilinx.com
0 Kudos
Highlighted
Adventurer
Adventurer
7,825 Views
Registered: ‎10-11-2011

I've attached the MHS.  Can you instruct me on how to do an XMD dump of the VDMA register space?  I know I can use rrd to see the system register values but I wasn't sure if that is what you needed.

 

This is a hardware project, built in EDK and I'm using a software application built in SDK for control.  I considered putting in chipscope probes but I haven't yet because I don't have much experience with it, and I'm not sure what exactly I would need to scope to help debug this problem.

 

The only values I'm seeing in the status register are 0x00010001 and 0x00010000.  The first is before I start the DMA running (by setting DMACR.RS to 1), and the second is the value after it starts running and it does not change from there.  The LSB gives the run/halt condition and bits 23 downto 16 are the Interrupt Frame Count Status, which is the interrupt frame count value (I believe this is linked to the Frame Count Enable?  Even with the DMACR.FrmCnt_IrqEn set to 1 thr core behavior appears the same).

 

I'm using version 5.00a of the VDMA core.

 

Minor edits for clarity.

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
7,820 Views
Registered: ‎08-02-2011

I usually use something like

 

mrd <address> <number of registers to dump>

www.xilinx.com
0 Kudos
Highlighted
Adventurer
Adventurer
7,818 Views
Registered: ‎10-11-2011
7E200000:   00010011
7E200004:   00010000
7E200008:   00000000
7E20000C:   00000000
7E200010:   00000000
7E200014:   00000000
7E200018:   00000001
7E20001C:   00000008
7E200020:   00000000
7E200024:   00000000
7E200028:   00000002
7E20002C:   500A0057
7E200030:   00010002
7E200034:   00010001
7E200038:   00000000
7E20003C:   00000000
7E200040:   00000000
7E200044:   00000000
7E200048:   00000001
7E20004C:   00000008
7E200050:   00000080
7E200054:   00000080
7E200058:   00000080
7E20005C:   C000FAF8
7E200060:   00000000
7E200064:   00000000
7E200068:   00000000
7E20006C:   00000000
7E200070:   00000000
7E200074:   00000000
7E200078:   00000000
7E20007C:   00000000
7E200080:   00000000
7E200084:   00000000
7E200088:   00000000
7E20008C:   00000000
7E200090:   00000000
7E200094:   00000000
7E200098:   00000000
7E20009C:   00000000
7E2000A0:   00000000
7E2000A4:   00000000
7E2000A8:   00000000
7E2000AC:   00000000
7E2000B0:   00000000
7E2000B4:   00000000
7E2000B8:   00000000
7E2000BC:   00000000
7E2000C0:   00000000
7E2000C4:   00000000
7E2000C8:   00000000
7E2000CC:   00000000
7E2000D0:   00000000
7E2000D4:   00000000
7E2000D8:   00000000
7E2000DC:   00000000
7E2000E0:   00000000
7E2000E4:   00000000
7E2000E8:   00000000

 This should be all the register values after running the program until it hangs in run mode.

0 Kudos
Highlighted
Adventurer
Adventurer
7,809 Views
Registered: ‎10-11-2011

I did just happen to think that the problem might be due to the IP downstream from the VDMA, since it's a custom core.  I'm going to try putting a simple FIFO or something similar downstream and see what my results are.  I'm also in the process of synthesizing chipscope into my current design and I'll post those results.

0 Kudos
Highlighted
Adventurer
Adventurer
10,296 Views
Registered: ‎10-11-2011

I ended up hooking up chipscope and found that the VDMA was in fact transferring to the downstream core (XFFT), but the XFFT was not functioning correctly (not transforming the data and outputing it) which caused the S2MM stream to never receive data from the XFFT output so the VDMA never returned to hold status.

View solution in original post

0 Kudos
Highlighted
Visitor
Visitor
6,560 Views
Registered: ‎07-17-2013

Hi David,

I have seen that you have faced an issue similar to mine with the AXI VDMA IP core.

If use the VDMA core in circular mode with 3 frames pointing to 3 different adress in DDR memory, the data sent to my DAC are fine and correct.

But if I try to use the VDMA core in non circular mode but in frame count enable, then I get an IRQ rising when the frame counter goes to 0 but I can't restart the DMA transfer in the way to update the data value or change the start adress of the VDMA.

Can you share your experaience with me on that frame count mode?

Thanks,

Regards.

Julien

0 Kudos