[TALK] Problems with Cortex-M7

[Davide2]

Hello, if cache invalidation for DMA is handled by the user, are there any issues or disadvantages to merge the ram3 zone with ram1 and ram2 into a contiguous ram0 ?

From :

ram0 : org = 0x20020000, len = 384k /* SRAM1 + SRAM2 */
ram1 : org = 0x20020000, len = 368k /* SRAM1 */
ram2 : org = 0x2007C000, len = 16k /* SRAM2 */
ram3 : org = 0x20000000, len = 128k /* DTCM-RAM */
ram4 : org = 0x00000000, len = 16k /* ITCM-RAM */
ram5 : org = 0x40024000, len = 4k /* BCKP SRAM */

To :

ram0 : org = 0x20000000, len = 512k /* SRAM1 + SRAM2 + DTCM-RAM */
ram1 : org = 0x20020000, len = 368k /* SRAM1 */
ram2 : org = 0x2007C000, len = 16k /* SRAM2 */
ram3 : org = 0x20000000, len = 128k /* DTCM-RAM */
ram4 : org = 0x00000000, len = 16k /* ITCM-RAM */
ram5 : org = 0x40024000, len = 4k /* BCKP SRAM */

Thank you !!

[steved]

Hello, if cache invalidation for DMA is handled by the user, are there any issues or disadvantages to merge the ram3 zone with ram1 and ram2 into a contiguous ram0 ?

The DTCM RAM (ram3) is never cached (by design), so its best used for variables where caching is a definite disadvantage (e.g. DMA-accessed RAM) - not sure about invalidating cache, but flushing cache will definitely take some processor time. I therefore suggest it is far better to manually assign variables to the ram3 zone, otherwise you could end up doing cache operations on uncacheable memory - probably harmless, but unnecessary, and may confuse someone in the future.

[Davide2]

Thank you for the answer.

Somewhat related question : I had ICache and DCache completely disabled. I had a DMA buffer in RAM3 for SDMMC1 aligned to 32 bytes. It did unaligned read sometimes. It worked fine. I re-enabled ICache/DCache and things went wrong when the reads where unaligned. How is this related as, if I understand correctly, these shouldn't impact RAM3 ?

[Giovanni]

Hi,

Have you read this article?

http://www.chibios.org/dokuwiki/doku.ph ... _dma_guide

It is all about the cache line size, buffers much be aligned in order to not corrupt adjacent data when invalidating the cache.

Giovanni

[Davide2]

Hello,

I did but as DTCM is never cached, how could it affect it ?

[Davide2]

I found this :

DTCM-RAM not accessible in read when the MCU is in Sleep mode (WFI/WFE)

Description
• The DTCM-RAM is not accessible in read during Sleep mode (when the CPU clock is
gated). When a read access to the DTCM-RAM is performed by an AHB bus master
(that are the DMAs) while the CPU is in sleep mode (CPU clock is gated), the data is
not transmitted to the AHB bus and the AHB master reads 0x0000_0000.
• There is no issue when a write is performed to the DTCM-RAM while the CPU is in
sleep mode, the data is correctly written in the DTCM-RAM.
Workaround
Use the AXI SRAM1 or SRAM2 for DMA data read transfers and use the AXI DTCM-RAM
for DMA data write transfers in Sleep mode.

http://www.st.com/content/ccc/resource/ ... 257543.pdf

And this :

If the DTCM-RAM is used as data location and the variables used are byte or/and halfword
types, since there is no ECC management in this RAM on the STM32F7 Series, it is
recommended to disable the read-modify-write of the DTCM-RAM in the DTCM interface (in
the DTCMCR register) to increase the performance.
To do this, add the following C code in SystemInit() in system_stm32f7xx.c file or at the
beginning of the main function:
__IO uint32_t * CM7_DTCMCR = (uint32_t*)(0xE000EF94);
* CM7_DTCMCR &= 0xFFFFFFFD; /* Disable read-modify-write */

http://www.st.com/content/ccc/resource/ ... 169764.pdf

[faisal]

How about including something like this in ChibiOS as a helper:

Code: Select all

/*
 * Macro to declare a cache-aligned buffer
 * Parameters:
 * T - The data type of the buffer elements
 * N - The number of elements in the buffer
 * name - The name of the buffer
 */
#define DECL_CACHE_BUFFER(T, N, name)             \
    /* Align the buffer to the cache line size */ \
    CC_ALIGN(CACHE_LINE_SIZE)                     \
    /* Declare the buffer with size aligned */    \
    T name[CACHE_SIZE_ALIGN(T, N)]

/*
 * Macro to check if a buffer is cache-aligned and its size is a multiple of the cache line size
 * Parameters:
 * buf - The buffer to check
 * nbytes - The size of the buffer in bytes
 */
#define CHECK_CACHE_ALIGNMENT(buf, nbytes) \
    /* Check if the buffer is aligned to the cache line size */ \
    osalDbgCheck(((uint32_t)(buf) & ~(CACHE_LINE_SIZE - 1)) == (uint32_t)(buf)); \
    /* Check if the buffer size is a multiple of the cache line size */ \
    osalDbgCheck((nbytes) % CACHE_LINE_SIZE == 0)


[Giovanni]

In cache.h you mean?

Giovanni

[faisal]

In cache.h you mean?

Giovanni

Sure - or wherever you think is suitable. FYI, updated my post above.

[Giovanni]

Hi,

The problem with that macro is that it works for arrays of 8 bits wide types; larger base types, plain scalars, structures are not covered. The generic approach would be to put the variable into a base-aligned union together with a size-aligned char array.

Code: Select all

union {
  T elements[N];
  char __dummy[CC_ALIGN_NEXT(sizeof T * N), 32);
} name;


And this only covers arrays, another macro would be needed for structured types and scalars. It also enforces to access the array using the "elements" field name so not 100% transparent.

Giovanni