The problem was that the interrupts the driver was waiting for (wait interrupts) did not include SDMMC_INT_DINT, the DMA Boundary Pause interrupt.
The calloc() / kmm_memalign() memory allocation put the buffer in a place where the SDMA Buffer Boundary was not encountered, so the SDMA Boundary Pause didn't happen. When I removed the extra memory allocation, the SDMA Boundary Pause happened, but: 1. The interrupts that the driver was waiting for didn't include the DMA Boundary Pause interrupt, so the driver never got a signal to wake up and restart the SDMA transfer 2. The driver wasn't handling SDMA Boundary Pause interrupts, so I had to add handling code for it. Just writing this here in case it helps anyone looking for how this was solved. I'm back on track. -adam On Wed, Jul 8, 2020 at 2:22 PM Adam Feuer <a...@starcat.io> wrote: > The kmm_malloc() also has the same effect of making it work. > > I think what's going on is that the transfer is passing a SDMA Buffer > Boundary— they are 4kb (configurable, but that's the default). SDMA pauses > when passing one, and needs to be reenabled by software. I can see the > SDMMC_INT_DINT being fired when I dump the SDMMC registers, but that > interrupt is not enabled for some reason... I'm trying to track it down now. > > -adam > > On Tue, Jul 7, 2020 at 9:09 PM Adam Feuer <a...@starcat.io> wrote: > >> Greg, >> >> Thanks. I'll change the call to kmm_malloc() or kmm_memalign() and see if >> that works too. >> >> cheers >> adam >> >> On Tue, Jul 7, 2020 at 9:03 PM spudaneco <spudan...@gmail.com> wrote: >> >>> I don't know anything about the DMA, but you should not call calloc() >>> from within the OS. That does not work in all configurations.Instead >>> include nuttx/kmalloc,h and call kmm_malloc(). If you want aligned memory, >>> call kmm_memalgn().Sent from Samsung tablet. >>> -------- Original message --------From: Adam Feuer <a...@adamfeuer.com> >>> Date: 7/7/20 9:40 PM (GMT-06:00) To: dev@nuttx.apache.org Subject: >>> driver question about memory and calloc Hi,I am getting the SAMA5D27 SDMMC >>> SD Card driver pull request ready. There'sone small issue I'm working on, >>> though. There's a place in the driverinitialization where I calloc() some >>> memory– 466 bytes. DMA data transferswhile reading from files times out if >>> I don't have the calloc() in there.With the memory allocated, everything >>> works fine. Nothing writes to thisblock of memory– I memset it and examined >>> it before, during, and aftertransfers using GDB. It's just an unused block >>> of memory.I'm trying to find out if other amounts of memory work– smaller >>> than about100 bytes doesn't work, and I know it works reliably at 466 >>> bytes. I'lltrack the exact number down tomorrow.But my question is, why >>> does this work? The driver datasheets< >>> http://ww1.microchip.com/downloads/en/devicedoc/ds60001476b.pdf>don'tmention >>> that the chip needs aligned memory for its buffers, and the Atmeland U-Boot >>> drivers don't use aligned memory. And since nothing isoverwriting the >>> memory, what is the calloc() doing to prevent the SDMMC DMAengine from >>> completing the transfer?If anyone has seen behavior like this, I'd love to >>> know it. I'd like totake this otherwise useless code out, or at least know >>> why I need it.Link to the specific line of code in sam_sdmmc.c< >>> https://github.com/starcat-io/incubator-nuttx/blob/feature/sama5d27-sdmmc-support/arch/arm/src/sama5/sam_sdmmc.c#L3737>cheersadam-- >>> Adam Feuer <a...@adamfeuer.com> >> >> >> >> -- >> Adam Feuer <a...@starcat.io> >> > > > -- > Adam Feuer <a...@starcat.io> > -- Adam Feuer <a...@starcat.io>
