DMA half transmission IRQ not called

LeafLabs Garden » Support » Maple IDE Support

DMA half transmission IRQ not called

(10 posts) (4 voices)

Started 3 years ago by Xavier
Latest reply from crenn

Xavier
Moderator
Hello,

I'm working on a maple_mini with libmaple 0.12.
I'm using DMA to feed a SPI double DAC (mcp4822)...

I'm trying to send both channel (left right) in one DMA request of 4 bytes. I need an interupt after 2 bytes to do some GPIO modification to validate the first channel.

First question : during the DMA half transmission IRQ, do the DMA transfer stop ?
Can i assume during the interupt that only 2 bytes have been sent and that it will continue only when the IRQ function exits ?

My main problem is that the DMA_HALF_TRNS is never called... DMA_TRNS_CMPLT works.
The consequences is that with the following i only have one of the stero channel working.

Here's the init :
```
    spi.begin(SPI_18MHZ, MSBFIRST, 0);
    dma_init(DMA1);
    spi_tx_dma_enable(SPI1);
    dma_setup_transfer(DMA1, DMA_CH3, &SPI1->regs->DR, DMA_SIZE_8BITS,
                        &samples, DMA_SIZE_8BITS, (DMA_MINC_MODE | DMA_TRNS_CMPLT
                        | DMA_HALF_TRNS | DMA_FROM_MEM));
    dma_attach_interrupt(DMA1, DMA_CH3, DMAEvent);
    dma_set_priority(DMA1, DMA_CH3, DMA_PRIORITY_VERY_HIGH);
```
Then in an IRQ called every 1/32768 sec (sampling frequency = 32768Khz):
```
    dma_set_num_transfers(DMA1, DMA_CH3, 4);
    dma_enable(DMA1, DMA_CH3);
```
And the DMAEvent function :
```
void DMAEvent() {
    //we get the DMA event
    dma_irq_cause event = dma_get_irq_cause(DMA1, DMA_CH3);
    if (event == DMA_TRANSFER_COMPLETE) {
        csHigh();
        dma_disable(DMA1, DMA_CH3);
        synth.incReadCursor();
    } else {
        csHigh();
        delay(100); // Tells me it never calls else it should not work with such a delay!!
        csLow();
    }
}
```
Is there any minimal number of bytes in the DMA transmition to be called in the middle ?

Thanks a lot for any help,

Xavier
Posted 3 years ago #
mbolivar
LeafLabs

dma_get_irq_cause() is a hack whose right to exist I've often questioned. It works fine in simple situations, but has unintuitive behavior in edge cases like these.

First question : during the DMA half transmission IRQ, do the DMA transfer stop ?
Can i assume during the interupt that only 2 bytes have been sent and that it will continue only when the IRQ function exits ?

No, you can't assume either. AFAIK, the DMA peripheral pends the interrupt then keeps going on with the transfer. This is likely the source of your problems, since your number of transfers is so small.

If you want to check every flag (error, half-complete, complete, etc.) individually, then dma_get_isr_bits()/dma_clear_isr_bits() is the pair of the functions you're interested in.

Here's my understanding of why you're seeing this behavior, and a proposed workaround:

The DMA status register bits (for half-transfer and transfer complete, etc.) get set regardless of whether you've got an interrupt enabled for them. Because of this, in your configuration, dma_get_irq_cause() first checks if the transfer complete flag is set. If so, it immediately returns DMA_TRANSFER_COMPLETE. Only if the transfer-complete status register bit is zero does it check if the half-transfer complete bit is set. This is necessary because if you only specify DMA_TRNS_CMPLT, the half-transfer _and_ transfer complete bits will both be set when the transfer completes.

In the case that your interrupt handler is called after half-transfer but before transfer complete, this works fine -- you get interrupted twice and everything works like you'd expect.

If the DMA transfer is small and completes in between the time the half-transfer interrupt pends and the time that your IRQ handler actually gets control and you call dma_get_irq_cause(), the transfer-complete flag might also have gotten set. You then get told your transfer is complete (which it is), and you never see DMA_TRANSFER_HALF_COMPLETE.

In other words, you may not get interrupted twice, as it's possible that the transfer could complete while the interrupt is still pending (during the time that libmaple's interrupt handler is running, before it calls your interrupt handler, or during register stacking before libmaple's interrupt handler even gets called, or during some other, higher-priority interrupt...). The DMA peripheral then pends an already-pending interrupt, and so you only get the single call. (dma_get_irq_cause() clears _all_ status bits, so you don't get re-interrupted for the half-transfer. If it didn't, then you'd be very confused, as you'd see DMA_TRANSFER_COMPLETE before seeing DMA_TRANSFER_HALF_COMPLETE!)

I think your best bet may be to transfer the first two bytes and check for DMA_TRANSFER_COMPLETE. The first time that happens, your interrupt handler can do the GPIO twiddling and then start the transfer of the other two bytes.

Posted 3 years ago #
mbolivar
LeafLabs

Here's the source for dma_get_irq_cause() in case it helps clear things up:

https://github.com/leaflabs/libmaple/blob/master/libmaple/stm32f1/dma.c#L261

Posted 3 years ago #
Xavier
Moderator

Thanks a lot for the explaination, that totally makes sens.

I get rid of the DMA for these few bytes transfer.
I laverage the non blocking SPI feature by setting directly my uint16 samples in the register :
SPI1->regs->DR = sample;
(I'm really after saving each CPU cycle ).
And it Works like a charm...

I had to modify "enable_device() " in HardwareSPI to replace SPI_DFF_8_BIT by SPI_DFF_16_BIT and recompile.
I could not find how to set the SPI_DFF_16_BIT using the library.

Did i miss something ?

I added a 12 bits DAC (mcp 4822) to my synth and use both channels... My synth is now stereo !!! :-)

Xavier

Posted 3 years ago #
mbolivar
LeafLabs

Glad things are working for you now!

I could not find how to set the SPI_DFF_16_BIT using the library.

Did i miss something ?

There's currently no way to set 16-bit data frames using HardwareSPI, so unless you want to drop down to the C layer, your workaround is your best bet for now. Perhaps we should add 16-bit data frame support to HardwareSPI? I hadn't run into a use-case for it yet, which is why I left support for it in spi.h only.

Posted 3 years ago #
Xavier
Moderator

You should get a mcp4821 DAC.
12 bits, 20Mhz SPI... $2.00.
It reads 16 bits command (4 control bits + 12 sample bits)...
So the SPI 16 bits is more than usefull.

Of course, buy one and play with it only when the maple II is ready ;-)

Xavier

Posted 3 years ago #
gbulmer
Moderator

Xavier - AFAICT the mcp4821/2 DACs are similar in capability to the two built in DACs in the Maple RET6, and STM32F4.

So are you using it to get extra DAC channels for your synth?

Posted 3 years ago #
Xavier
Moderator

Several reasons...

I've never tried the built-in DACS of any STM32.
My synth uses the Maple mini so i don't have any DAC to compare.

I'll use the 4922 which has an external ref that will allow me to plug a volume pot.
The output V range can be higher 0->4.5V...

I also trust more external DAC for signal/noise ratio reasons... but i may be wrong, i have no idea how good the buil-in DAC work.

I saw an old thread about :
http://www.ghielectronics.com/catalog/product/353
Did you try it ?

Were there any official words about a "mini" in the maple2 family ?

Xavier

Posted 3 years ago #
mbolivar
LeafLabs

Were there any official words about a "mini" in the maple2 family ?

No word. There aren't any LQFP48 STM32F4s last I checked, so it'd have to be the same 64-pin chip used on Maple 2. That's too big for the current Mini form factor, so the idea is shelved.

Posted 3 years ago #
crenn
Moderator

However there is a LQFP48 STM32F3!
http://www.st.com/internet/mcu/product/253449.jsp

That would be equivalent to what the Maple Mini has now but with the Cortex-M4F core.

Posted 3 years ago #

RSS feed for this topic

Reply

You must log in to post.