Hey guys. I'm performing a design which contains a mSGDMA conected to a SoC SDRAM port. I could get it to write data onto the SDRAM by using a Modular SGMDA Dispatcher and a Write Master (two different IPs), although when I tried to write a greater length than 0xF into the descriptor the core would stuck in busy mode and wouldn't perform any transfer to the SDRAM. Let's say, if I try to write 0xDEADBEEFDEADBEEF (8 bytes) to the SDRAM address 0x30000000 I'm able only by setting the descriptor length to 0xF, otherwise it won't work (and with the length of 0xF the SDRAM receives 16 bytes). Theoretically if I put 0xFFFFFFFF in the length field it will perfom a write of 0xFFFFFFFF bytes? This means that one descriptor is capable of sending that amount of data to the SDRAM? What I'm trying to do is to send streaming data to the mSGDMA so the data can be written into an address range from SDRAM (let's say 0x3000 0000 - 0x3fff ffff). Do I need to use multiple descriptors to perform this or I'm able to use only one descriptor and reissue it (the Park Writes in the Control Bit Field Definition) and also the 'End on EOP' bit field? I am asking this cause I couldn't perform multiple writes onto the SDRAM and I have to keep writing a new descriptor everytime. Also, I keep track the Write fill level from the CSR Register and it is stuck at one. This means that Write Master FIFO isn't getting filled?

What is your burst size set to in the mSGDMA? Here's a post I made last July about a problem I was seeing whenever my transfer size was larger than the mSGDMA burst size: http://www.alteraforum.com/forum/showthread.php?t=52773&p=216944#post216944 This was on an Arria 10 SoC, which we eventually abandoned in favor of a non-SoC Arria 10. So I'm no longer working with the mSGDMA and I never did resolve the problem I was seeing.

--- Quote Start --- What is your burst size set to in the mSGDMA? Here's a post I made last July about a problem I was seeing whenever my transfer size was larger than the mSGDMA burst size: http://www.alteraforum.com/forum/showthread.php?t=52773&p=216944#post216944 This was on an Arria 10 SoC, which we eventually abandoned in favor of a non-SoC Arria 10. So I'm no longer working with the mSGDMA and I never did resolve the problem I was seeing. --- Quote End --- I was just reading this topic this afternoon. I guess my problem is related with the length field of the descriptor. As the documentation says, it is the number of transfer that the Write Master issues to the SDRAM. The thing is that I can't just increase the length size to perform a transfer of 1KB. It only allows me to transfer 16 bytes. In my design I turned off the burst mode as it doesn't help me much here (or I think it doesn't... lol). However, have you had problems with this length thing?

--- Quote Start --- However, have you had problems with this length thing? --- Quote End --- My problem was specifically related to burst transfers that required more than one burst. They just didn't work, in simulation or in hardware. Without bursts you're transferring single 16-byte words at a time (essentially a burst with one beat of data). If you try to transfer > 16 bytes then more than one beat of data is required, and that does not work. Sounds very similar to my problem. I hope you get to the bottom of this and can share what you find out. I highly recommend opening an SR (service request) with Altera technical support. I would have done that but we abandoned the design and moved on.

I am facing a nearly identical situation, have you made any progress on this?

As I said above, we bailed on the SoC design. The only reason I was using the mSGDMA in the first place was to leverage the software drivers that knew how to use it. When we abandoned the SoC I abandoned the mSGDMA, so I never followed up. I still recommend the service request route if you want to get this resolved.

mSGDMA ST-MM to SDRAM - Issue | Altera Community

12 Replies

Altera_Forum
Honored Contributor
8 years ago
--- Quote Start ---
Hey, Robin!

The first time I put the system to work I had the same problem, but since it has been a couple of months since I solved it, I don't remember what is the exact solution. However, I can point out some situations so you can debug and see if it works with your design.

# 1 - Add the line "run bridge_enable_handoff;" in your u-boot and compile it again (and put the new u-boot in the sdcard). You can add this line right after the line "setenv bootimage zImage;". This way you can be sure the bridge is enabled.
# 2 - Since your HPS freezes, I'm sure# 1 won't be your problem. What I think it happens is that your software messes up with the bridge and the system halts (I ran to the same problem. After the DMA transfered one packet of data I would loose communication with the board). Check if your streaming interface allows "sop" and "eop". If it does, then you have to check on SignalTap if you are generating these signals correctly. It might be a software problem as well... how are you configuring the dispatchers? Paste the code here if u want me to take a look!
# 3 - Use SignalTap to see how your transfer starts and ends.

Also, I'm quite sure that you have to enable the bridge communication while booting the device. If you wanna do that, follow this tutorial:
https://rocketboards.org/foswiki/view/documentation/embeddedlinuxbeginnersguide

Basically to compile an u-boot you will create a file called "boot.script"" and write this onto it (and other commands u want so you can modify your u-boot)
echo -- Programming FPGA -- fatload mmc 0:1 $fpgadata soc_system.rbf;fpga load 0 $fpgadata $filesize;run bridge_enable_handoff;echo -- Setting Env Variables --setenv fdtimage soc_system.dtb;setenv mmcroot /dev/mmcblk0p2;setenv mmcload 'mmc rescan;${mmcloadcmd} mmc 0:${mmcloadpart} ${loadaddr} ${bootimage};${mmcloadcmd} mmc 0:${mmcloadpart} ${fdtaddr} ${fdtimage};';setenv mmcboot 'setenv bootargs console=ttyS0,115200 root=${mmcroot} rw rootwait; bootz ${loadaddr} - ${fdtaddr}';run mmcload; run mmcboot;

And after doing the previous step you need to compile the script. You can do it by running this command:

mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n "Boot Script Name" -d boot.script u-boot.scr

After that replace the u-boot.scr from your sdcard to the one you compiled.

Let me know if this helps or if you have doubts about anything else. Cheers.

Regards!
--- Quote End ---

Hello Marcio,

At this point, all major steps in the code resemble the CL project, found here: https://support.criticallink.com/redmine/projects/mityarm-5cs/wiki/writing_to_hps_memory . The only difference with the CL project is that I give the FPGA only 200MB DDR-RAM and that the discriptor.length is 32*4 instead of 0xFFFFFFFF. However, since this should be a working project, I do not think there would be an error there. You are always free to take a look though :)
I will try the things you said later today, thank you for your input! much appreciated!

KR,
Robin
Altera_Forum
Honored Contributor
8 years ago
--- Quote Start ---
...
--- Quote End ---

Hello Marcio,

A quick question. When you wrote the code for your mSGDMA, how did you write it, did you use the NIOS II IDE in combination with the HAL libraries?

KR,Robin

Forum Discussion

mSGDMA ST-MM to SDRAM - Issue

12 Replies

Recent Discussions

NiosV µC/OS-II

Recommended Quartus Prime Standard Edition for Nios V Development on MAX 10 FPGA (10M25DAF4817G)

AshlingRISCFree IDE Build system: 'source directory does not appear to contain CMakeLists.txt"

Nios-V on Cyclone IV

Debug Know-How: Ashling* RiscFree* NIOS® V debug using Command Line