We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

Showing results for 
Search instead for 
Did you mean: 
Participant ejubenville
Registered: ‎10-17-2008

Will an AXI DataMover hard reset recover from a shortened S2MM transfer?

Is a hard reset of the AXI DataMover S2MM port expected to recover fully from a shortened (aborted) transfer? 


We use an S2MM DataMover in our IP to transfer acquisition data into memory,  We generally send a single command into the DataMover to transfer a large block of data.  Everything works fine if we let it acquire the totality of bytes (BTT) that we had originally commanded to the DataMover.  However, if we terminate our acquisition early, we cannot get another DataMover S2MM transfer to work properly unless we physically reboot the Zynq.


With Chipscope, we can watch TDATA, etc,, on the problem transfers from our IP to the DataMover, and everything looks fine, but the data doesn't end up in the commanded memory locations.  Strobing the DataMover's m_axis_s2mm_aresetn input doesn't fix the problem.  Neither does supply our PL with its master global reset restoring it's own power-up state.  The system behaves as though the AXI interconnect, or something upstream, is messed up, and can only recover by a reboot that exercises the AXI bus reset(s).


We are not currently doing a soft shutdown using the DataMover's s2mm_halt input,  We rationalized that to be unnecessary if we do a hard reset via the m_axi_s2mm_aresetn input.  Is a soft shutdown a requirement whenever BTT is not fulfilled?


We are not using interdeterminate BTT mode, either.


Any advice?


0 Kudos
1 Reply
Participant ejubenville
Registered: ‎10-17-2008

Re: Will an AXI DataMover hard reset recover from a shortened S2MM transfer?

Update... The data stored during the failed acquisition is placed into the wrong memory locations, in circular fashion.  In other words, the commanded start address of the destination memory isn't where the first acquisition sample winds up.  The first acquisition sample winds up in a memory location dependent on how much progress was made during the previous acquisition. 


It appears that the address auto-increment logic in the DataMover isn't being reset by asserting and deasserting s_axi_s2mm_aresetn.

0 Kudos