UC3A364 USBB DMA question

Go To Last Post
6 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm trying to interpret the behavior of the device-mode DMA on and OUT HS ISO endpoint. I (think I) understand the case where a USB packet is smaller than the DMA transfer so multiple OUT packets may be sourced to satisfy one DMA transfer. But what about the other way around?

What if, say a 512 byte OUT packet is received and the some linked transfers specify only 128 bytes each? Will the OUT packet be used to source (spread across) multiple DMA requests (provided the DMAENDEN bit is 0 - doc32072.pdf, ppg713) ?

Thanks!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well... The answer is yes. One USB OUT packet will be spread across multiple DMA requests until the DMA BYCT is satisfied. Then, any remaining bytes in the USB EP buffer will be used to satisfy the next DMA transfer.

tap tap... Is this thing on???

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

USB DMA is a rather complicated issue, so some threads end up unanswered. I was away on vacation, but maybe it’s not too late now.

You got that right with one USB OUT packet getting split over several DMA requests. You can decide what happens after the end of the DMA transfer, though. The UDDMAnCONTROL register allows you to configure what happens when the DMA controller is set up to transfer more or less than the size of a complete or incomplete (short) USB packet. By default, residual data stays around until you pick it up with a subsequent transfer, which is what you observed. Alternatively, you can configure the endpoint to discard all residual data at the end of the DMA transfer. This should be explained somewhere in section 27.7.4 USB DMA Operation.

Not sure if this was actually your question. If not and you still want to know, please rephrase your question.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi and thanks for answering. I'm having an issue getting DMA working on a HS ISO USB endpoint. The datasheet is devoid of any examples for a HS ISO IN endpoint, it says simply that "The following example refers to OUT endpoint. For IN endpoint the programming is symmetric." BS! Here's what I'm trying to achieve:
Count and buffer audio samples until msof comes along at which time I want allow DMA to send the number of sample accumulated thus far to the host. Simple right?? When msof | sof occurs should I just write the BYCT and other regs and fire off the DMA? What about setting FIFOCON? It doesn't seem like setting auto-bank switching is the right thing to do, though there is no mention of how it works with IN EPs...

Can anyone explain how auto-bank switching works with HS ISO IN EPs???

I am currently just writing samples as they happen to the USB IN EP DPRAM then setting FIFCON at each msof (and sof). This works but I'm getting sporadic HSB stalls I believe because the OUT EP DMA is using burst DMA and the periodic writes of sample data to IN EP DPRAM seems to be causing one or the other to stall. I have adjusted HMATRIX arbitration but the issue persists. It seems to me that I could avoid the periodic stalls or at least trade them for one deterministic stall by allowing DMA to handle the IN EP as well as the out.
I get why an OUT EP would need auto-bank switching, but how will that work with an IN EP?

Any help understanding the behavior of HS ISO IN DMA will be greatly appreciated!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your post is a bit confusing. I’ll try to answer the proper questions...

wdawson wrote:
The datasheet is devoid of any examples for a HS ISO IN endpoint, it says simply that "The following example refers to OUT endpoint. For IN endpoint the programming is symmetric." BS!
Swearing will not get you a quicker answer. I believe it works pretty much just as the datasheet says, even for IN EPs. Well, except for DMAEND_EN, which you need if you send short/partial packets, i.e. less than what you claimed to send for your ISO transfer.
wdawson wrote:
When msof | sof occurs should I just write the BYCT and other regs and fire off the DMA?
Yes, pretty much. Here’s what I do to get a DMA transfer rolling:
- set UDDMAx_ADDR to the data start address
- set UDDMAx_CONTROL to the transfer length with EOBUFF_IRQ_EN, DMAEND_EN and CH_EN set (I use IRQs)

As the datasheet says, DMAEND_EN properly sends your data at the end of the DMA transfer. This means no stalls. You might need automatic bank switching, see below.

wdawson wrote:
What about setting FIFOCON? It doesn't seem like setting auto-bank switching is the right thing to do, though there is no mention of how it works with IN EPs...

Can anyone explain how auto-bank switching works with HS ISO IN EPs???

It’s been a while since I wrote that code, but I believe my application doesn’t touch FIFOCON at all. I have automatic bank switching enabled and that takes care of everything.

FIFOCON is needed to release a bank when you’re done using it. With auto-switching disabled on an IN EP, the DMA controller reads from the bank until it is empty. If the DMA transfer is finished, the bank is not released and you’ll have to do it manually. Not sure whether the bank is released when there’s more to do for the current DMA transfer, leaving only the last bank unfreed, or whether the DMA transfer actually stalls when it has more to do but the current bank is empty. At any rate, when you’ve got auto-switching enabled, the bank is always released when it contains no more data and if the DMA transfer has more to do, it continues with the next bank. This is usually what you want, I believe.

I’m using it for HS bulk EPs, btw. Not sure how applicable this is to HS ISO endpoints, but it should be.

wdawson wrote:
I am currently just writing samples as they happen to the USB IN EP DPRAM then setting FIFCON at each msof (and sof). This works but I'm getting sporadic HSB stalls I believe because the OUT EP DMA is using burst DMA and the periodic writes of sample data to IN EP DPRAM seems to be causing one or the other to stall. I have adjusted HMATRIX arbitration but the issue persists. It seems to me that I could avoid the periodic stalls or at least trade them for one deterministic stall by allowing DMA to handle the IN EP as well as the out.
I don’t believe the stalls you’re experiencing are related to HMATRIX congestion. I’d rather blame it on manually setting FIFOCON, because I found it quite tricky to get that right during initial testing. I moved to automatic bank switching after a while and all those problems went away.

wdawson wrote:
I get why an OUT EP would need auto-bank switching, but how will that work with an IN EP?
Let’s say you do a 100 byte IN transfer with a 512 byte bank and auto-switching disabled. After writing 100 bytes to the bank via the DMA controller, nothing happens and you’ll have to set FIFOCON to say “there’s no more data coming, send this as a short packet”. Only then will the bank’s content be sent to the host and the bank will be empty and available again.

Now let’s say we use the same scenario with auto-switching enabled. After writing 100 bytes to the bank via the DMA controller (with DMAEND_EN set), those 100 bytes are immediately sent to the host as a short packet and the bank is empty and available again.

I hope this cleared things up a bit.

I strongly recommend using the set-up below for both IN and OUT EPs.

- enable automatic bank switching for IN and OUT EPs as soon as the USB set configuration packet is handled
- for IN endpoints, set UDDMAx_ADDR, then set UDDMAx_CONTROL to the transfer length with DMAEND_EN and CH_EN set (set EOBUFF_IRQ_EN if you use interrupts)
- for OUT endpoints, set UDDMAx_ADDR, then set UDDMAx_CONTROL to the transfer length with CH_EN set (set EOBUFF_IRQ_EN if you use interrupts)
- never touch FIFOCON (or any of it’s macros if you use the ASF)

Works like a charm, especially with interrupts.

Note: If you want to send data via an IN EP with several DMA transfers, set DMAEND_EN only on the last transfer to get the best speed. This will accumulate data until the bank size is reached, send the full bank, then continue with the next bank, and finish with a short packet at the end.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks so much for the prompt response! I will digest this and try some things. Thanks also for the correction my use of abbreviated profanity. I let my frustration get the best of me. ;)

Thanks again!