RT1064 Concurrent uSDHC & FlexSPI issues?

cancel
Showing results for 
Search instead for 
Did you mean: 

RT1064 Concurrent uSDHC & FlexSPI issues?

Jump to solution
604 Views
p_shep
Contributor III

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.

Labels (1)
Tags (3)
0 Kudos
1 Solution
586 Views
kerryzhou
NXP TechSupport
NXP TechSupport

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

View solution in original post

0 Kudos
4 Replies
587 Views
kerryzhou
NXP TechSupport
NXP TechSupport

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

0 Kudos
582 Views
p_shep
Contributor III

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.

0 Kudos
572 Views
p_shep
Contributor III

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?

569 Views
p_shep
Contributor III

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