RT1064 Concurrent uSDHC & FlexSPI issues?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

RT1064 Concurrent uSDHC & FlexSPI issues?

Jump to solution
1,522 Views
p_shep
Contributor IV

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
1,504 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
1,505 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
1,500 Views
p_shep
Contributor IV

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
1,490 Views
p_shep
Contributor IV

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?

1,487 Views
p_shep
Contributor IV

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