Tom -
What do you have the burst size configured to in the mSGDMA for the f2h_sdram interface? I had a problem with the mSGDMA that I've been meaning to open a SR about. In my case it was an Arria 10 SoC design and the mSGDMA was MM to streaming vs. your MM to MM. But my problem was also on the f2h_sdram MM interface. What I saw was that if the mSGDMA MM burst size (f2h_sdram interface) was smaller than the transfer size then the f2h_sdram interface would hang. If the MM burst size is smaller than the transfer size then the mSGDMA must submit more than one read request to the MM interface to complete the transfer. Let's say the burst size is 256 bytes and the transfer size is 1024 bytes. The mSGDMA will submit 4 256-byte read requests to the MM interface in rapid succession (the MM interface buffers the requests). The MM interface then completes the first 256-byte burst transfer and stops. The mSGDMA is stuck waiting for the remaining three bursts that never come.
I saw this in simulation using an Avalon BFM to model the f2h_sdram interface. What I described happened 100% of the time whenever the transfer size was larger than the MM burst size. I was never able to clearly capture this happening in hardware with SignalTap but other than that the hardware was behaving the same as simulation: Whenever the transfer size exceeded the burst size the mSGDMA was stuck busy waiting for data from the HPS.
So my advice is to configure your mSGDMA burst size to be the same size as your configured maximum transfer size and see what happens. Or at least test with a transfer size that is <= to your configured burst size.
I always hesitate to submit SRs for complicated problems like this because the SR process gets bogged down in an endless back and forth between time zones that are 10-12 hours apart. But I'll get around to it eventually. I still don't know 100% that the problem in hardware was exactly what I saw in simulation, but from what I could see it looked like it was.
Good luck. Please post back what you see.
Bob