Showing results for 
Show  only  | Search instead for 
Did you mean: 
Registered: ‎09-30-2011

How do you reset the AXI DMA IP

We are using the AXI DMA IP core on a Zynq device running yocyo generated linux. Occasionally the DMA transfers result in a error and the LogicCORE IP or driver or both hang. We are looking for a way to reset the driver and IP so that we can restart. Attempts at stopping the channels seem to result in nothing good and the IP appears lost or inaccessible or non-reponsive. We cannot do any transfers. If we unload the driver and reload it, that does clear things up but that's not really a solution. 

I was wondering if anyone could describe a fail-safe reset sequence for the Xilinx AXI DMA IP that allows the whole SW/HW stack to restart without issue.

Tags (4)
0 Kudos
4 Replies
Registered: ‎08-21-2012

Subscribed for interest. I see the same problem in Linux.  It seems once a DMA receive is configured, it must complete, otherwise a driver unload/reload is required. There doesn't seem to be a clean way to shutdown otherwise. Killing the thread or process before or after stopping the engine doesn't work. I stumbled across an old post somewhere where a guy claimed fixing this involved both an HDL and driver change, but there was no further information so not sure how reliable that info is.

0 Kudos
Registered: ‎05-21-2015,

I'm not sure it would be possible to reset the DMA mid-transfer.  The problem stems from the AXI spec itself.  According to the AXI spec, every transaction *must* get a response.  There's no way to drop a transaction currently in process if you want to reset things.  As a result, if you have a misbehaving slave IP that drops requests--your design is likely to get stuck.

There are a couple solutions to this.

  1. First, there's a "AXI firewall" that you can look up.  This core "Provides protection for the upstream network (SI connection) from failures of the downstream network (MI connection).  When a failure is detected, the firewall becomes blocked, preventing further transfers from propagatin.  When the firewall becomes blocked, the SI generates compliant responses for all outstanding and subsequent transactions.  It also has separate blocks for read and write transactions.
  2. Alternatively, there's an open source AXI"bus fault isolator".  Like the AXI firewall, it needs to be placed between the slave and the interconnect, and guarantees that a misbehaving slave still meets the rules for an AXI interface.  It does this by 1) detecting a fault, and then 2) returning valid data following a fault but with the bus error flags set.  That way an AXI master interacting with the core might not die, but rather detect and (recover) from an error.  Also, like the AXI firewall, it will raise a flag that you can use with ILA or some other form of scope to see what caused the problem.
  3. Alternatively, if you set the OPT_SELF_RESET flag within the core, then the bus fault isolator will automatically issue a reset to your core to give it a chance to recover.  Either way, requests will always be returned within a user-selectable timeout -- either from the original core or from the bus fault isolator.

While it's not quite what you are asking for, you may find these cores meet your needs.


0 Kudos
Registered: ‎07-03-2014


I don't know if this helps, but I had the same problem with a DMA core in a baremetal system. Here is the solution that worked for me.


0 Kudos
Registered: ‎09-30-2011

Thank you for some ideas to pursue!
0 Kudos