Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
9 years ago

msgdma stuck in busy state

Hello :)

I have a problem with the msgdma. When I submit a descriptor to it and set the go bit it keeps in busy state.

I'm using the SoCKit with Cyclone V and Quartus 14.1

The msgdma is connected to a f2h_sdram port as an avalon-MM master for read and write

I used the following setup for the msgdma:

MM to MM

Data Width: 32

Data Path FIFO Depth: 32

Descriptor FIFO Depth: 128

Response Port: disabled

max Transfer length: 1 KB

aligned access

everything other disabled.

To initialize the msgdma I reset it by setting the "stop dispatcher" bit and after this the "dispatcher reset" bit. The status after this is "Response buffer empty" and "descriptor buffer empty".

After the initialization I send "stop descriptors" and create the descriptors and send them to the descriptor register. When I send the control part of the descriptor I have the "go" bit set. After this i unset "stop descriptors".

Immediately after this the status changes to "Response buffer empty" and "busy" and stuck at this...

Does anybody have an idea why the msgdma could keep in busy?

EDIT: If you need any additional information just tell me :)

Thx Tom

19 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Hey Bob

    I got the Problem...

    It wasn't my Qsys configuration, it was the environment variables in u-boot. The variable fpga2sdram_handoff was set to 0x0, i changed it to 0x00003fff to activate the f2h_sdram bridge. Now it works, or let me say I got other problems :rolleyes: :D

    I will try if I have the same problem with transfer size and burst size like you.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- Quote Start ---

    Hey Bob

    I got the Problem...

    It wasn't my Qsys configuration, it was the environment variables in u-boot. The variable fpga2sdram_handoff was set to 0x0, i changed it to 0x00003fff to activate the f2h_sdram bridge. Now it works, or let me say I got other problems :rolleyes: :D

    I will try if I have the same problem with transfer size and burst size like you.

    --- Quote End ---

    That's great to hear. Hopefully you don't have any other issues!
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    I think that the Avalon-MM BFM simulates the IP generated by Qsys, not the hard IP used by the ARM core. It may not be a valid simulation.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- Quote Start ---

    I think that the Avalon-MM BFM simulates the IP generated by Qsys, not the hard IP used by the ARM core. It may not be a valid simulation.

    --- Quote End ---

    I've been using the mSGDMA Qsys IP-- not the Arm DMA IP. I haven't run a simulation, but the Arm DMA IP is the Corelink DMA-330-- this is a very different beast.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    After consulting with Altera support, the mSGDMA core does have a bug and slightly different operation from the manual. According to them, the SW_RESET bit needs to be set and then cleared BY SOFTWARE to correctly reset, due to some bugs in the FIFO resets. This means that the reset bit doens't automatically return to zero to indicate a reset complete when in certain states. I can post the Altera support reply if anyone is interested. Hopefully the IP core bug and documentation can be synchronized.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- Quote Start ---

    After consulting with Altera support, the mSGDMA core does have a bug and slightly different operation from the manual. According to them, the SW_RESET bit needs to be set and then cleared BY SOFTWARE to correctly reset, due to some bugs in the FIFO resets. This means that the reset bit doens't automatically return to zero to indicate a reset complete when in certain states. I can post the Altera support reply if anyone is interested. Hopefully the IP core bug and documentation can be synchronized.

    --- Quote End ---

    I know it's an year later, but I'd appreciate the Altera support reply.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Me too, actually. The reply was basically that there was a bug. If you read the release notes for Quartus, it sounds like the FIFO reset bug is fixed. I haven't tested it though as I built a workaround in RTL to manage the FIFO bug. The mSGDMA has been working pretty well.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- Quote Start ---

    Me too, actually. The reply was basically that there was a bug. If you read the release notes for Quartus, it sounds like the FIFO reset bug is fixed. I haven't tested it though as I built a workaround in RTL to manage the FIFO bug. The mSGDMA has been working pretty well.

    --- Quote End ---

    Thanks. Not sure what is the issue that I'm running into then. When I set the reset bit in the control register, it clears itself automatically, but the resetting bit in the status register never gets deasserted. The whole thing hangs up, stuck in a resetting state.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- Quote Start ---

    Thanks. Not sure what is the issue that I'm running into then. When I set the reset bit in the control register, it clears itself automatically, but the resetting bit in the status register never gets deasserted. The whole thing hangs up, stuck in a resetting state.

    --- Quote End ---

    I remember having this issue as well, at one point. It depended on what mode the mSGDMA was already running in. If it was in a state that it couldn't reset from (ie certain "park" modes), then resetting was troublesome.