RT1064 Concurrent uSDHC & FlexSPI issues?

[p_shep]

Hi all,

I'm having odd issues during eMMC reads, where I get a memory management exception when allocating memory during a uSDHC transfer.

Running FreeRTOS on the RT1064, using the whole 8MBytes of HyperRAM as the heap, and have a eMMC device attached where the occasional read/write occurs, but not often.

We don't see exceptions all the time, but when they do, without fail I have one thread waiting on a  read transfer, while another thread is allocating or deallocating memory.

There's no reason these two events should interfere with each other, which is why I'm wondering if there's some hardware interference. That there are problems with transferring data over uSDHC at the same time as FlexSPI?

Maybe something to do with the allocation halting all tasks?

The Interrupt priority for the uSDHC is set to 4, so below the system int.

Generally the system is otherwise pretty stable.

I'm running out of idea to fix this.

[kerryzhou · Accepted solution]

Hi @p_shep 

  I think your issue is related to the cache, please read our RT cache application note, you can find the SDHC, you need to take care of the data coherency by cache operations.

  Please read the following application note:

https://www.nxp.com/docs/en/application-note/AN12042.pdf

Wish it helps you!

Best Regards,

Kerry

[p_shep]

Thanks.

I had wondered about that, but as far as I can tell the uSDHC driver only needs a 32-byte buffer in non-cached RAM, (s_sdmmcHostDmaBuffer), which I've located in DTCM and explicitly disabled cache on the whole of DTCM with the MPU:

/* Region 3 setting: Non-executable, Memory with Normal type, not shareable, non-cacheable */
MPU->RBAR = ARM_MPU_RBAR(3, 0x20000000U);
MPU->RASR = ARM_MPU_RASR(1, ARM_MPU_AP_FULL, 1, 0, 0, 0, 0, ARM_MPU_REGION_SIZE_256KB);

I'll set the whole of my HyperRAM as write-through, see if that helps.

[p_shep]

Well how about that, changing write-back to write-through seems to have worked!

Not a great solution performance-wise mind. 

I guess the uSDHC needs more than just that 32byte buffer, presumably the whole area it writes to.

I'm using the NXP drivers for this - maybe I can add the D-cache clean to the transaction complete interrupt?

[p_shep]

Ah, I already have enabled

/* Initialise the eMMC structs */
s_host_.dmaDesBuffer = s_sdmmcHostDmaBuffer;
s_host_.dmaDesBufferWordsNum = BOARD_SDMMC_HOST_DMA_DESCRIPTOR_BUFFER_SIZE;
s_host_.enableCacheControl = kSDMMCHOST_CacheControlRWBuffer;

hmmm