Jump to content
  • 0

Arty A7 Microblaze DMA Hangs on send


jmckinney

Question

I am running a Microblaze design with the freertos bsp on a Digilent Arty A7. My microblaze design uses the Arty's DDR, Ethernet, and UART. It has an AXIDMA, an interrupt controller and a timer I think. I have an AXI-S interface exiting my block design and talking to a custom IP, as well as a System ILA.

 

When I run/debug the xaxidma_example_sg_poll example code (from https://github.com/Xilinx/embeddedsw/tree/master/XilinxProcessorIPLib/drivers/axidma/examples) I can see the proper data (0x0C - 0x2B) come out of the microblaze and onto the AXI-S interface using my ILA. but the code doesn't ever return from:

 

(xaxidma_example_sg_poll.c - main) ..Status = SendPacket(&AxiDma);

(xaxidma_example_sg_poll.c - SendPacket) ..Status = XAxiDma_BdRingToHw(TxRingPtr, 1, BdPtr);

(xaxidma_bdring.c - XAxiDma_BdRingToHw) .. XAxiDma_WriteReg(RingPtr->ChanBase,

XAXIDMA_TDESC_OFFSET, (XAXIDMA_VIRT_TO_PHYS(RingPtr->HwTail) & XAXIDMA_DESC_LSB_MASK));

 

Looking at the ILA, all the AXI-S signals seem right. TVALID is high only during the transfer. TREADY is always high.

 

Has anyone had to deal with this or similar types of issues, with the stock dma sg example code?

 

After doing some more debugging, I am still stumped. In the HW, removed my AXI-S peripheral and replaced it with a direct loopback and see the same behavior on the software side, on the hardware side the AXI-S interfaces look the same, minus the latency my AXI-S peripheral was inducing. I've looked at the example code and added printf's all over the place, and observed the BD chain initialization for both the RX and TX channels. I've changed the packet size from the default of 0x20 bytes to 0x200 bytes.

 

According to the UG, the "XAxiDma_WriteReg(RingPtr->ChanBase, XAXIDMA_TDESC_OFFSET, (XAXIDMA_VIRT_TO_PHYS(RingPtr->HwTail) & XAXIDMA_DESC_LSB_MASK))" command is the actual write that starts the DMA HW reading the BD chain, and I have observed that.

 

The WriteReg command is is an alias of xil_out32() and so for it to not return seems to imply either some logic error on the AXIDMA axi-lite interface or some error in the my Block Diagram design that enables a register write to hang forever.

 

But the fact that I see the entire packet go out on the AXI-S interface, implies that, at the least the axi-lite write enable / write strobes get there.

 

It might be notable that the BD ptr (81000000) that is written into the TDESC_OFFSET register is the First/Head BD. The example code appears to check for TXSOF and TXEOF, and appears to send a single packet that lives at one contiguous memory location, so that seems like only processing 1 BD would be correct.

 

It's also notable that the xaxidma_sg_intr.cc and xaxidma_sgcyclic_intr.cc examples hang at the same call, on XAxiDma_bdringToHw(TxRingPtr...).

 

I’ve added another ila to look at the axi-lite interface to the DMA. It looks right too. I can see the TAILDESC data value (0x81000000) going on WDATA line, The TAILDESC addr (0h010) going on the AWADDR line in clk later, then both the AWVALID and WVALID lines going high 2 clks later, The AWREADY and WREADY signals gloing high it looks like 23 clocks later, and then both the VALIDs and READYs dropping 1 clk later, and then 1 clk later the BVALID goes high and 1 clk later BVALID and BREADY drop low.

 

I’m running out of ideas. 1) modify the example to process and send 2 BDs. 2) Add a slice register to the AXI interconnect on that MAXI port? 3) tinker with the code to see if I can ever execute a read/write to the the TAILDESC register?

 

Everything seems right but the processor hangs. “stalled on memory access.”

Link to comment
Share on other sites

1 answer to this question

Recommended Posts

  • 0

Hi @jmckinney

I'm largely not familiar with FreeRTOS, but is there a chance that the data cache could be messing with the ability of the DMA to pull block descriptors from memory? https://www.freertos.org/FreeRTOS_Support_Forum_Archive/May_2016/freertos_Zync_UDP_TCP_with_DMA_IP_f531ef1cj.html seems potentially relevant. Caching issues are a pretty standard problem with non-scatter-gather DMA, where it just makes data unable to be seen by either side unless you flush or invalidate as appropriate. Pointers in block descriptors that aren't coming through as expected could cause all sorts of issues. If that's the cause, might be worth trying to disable the caches entirely, though I'm not sure how this affects the FreeRTOS setup.

If you haven't, I'd also try putting an ILA on the DMA's AXI4-full master interfaces.

Thanks,

Arthur

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...