Question about Level1 Cache STM32F7

[Gunnar Bohlen]

Posted on November 08, 2017 at 10:11

Hello,

I have read several documents about the Cache, but the last sentence in AN4839 (Level 1 cache on SRM32F7 Series) confuses me.

'

However, If the external device is an ASIC and/or a FIFO, the user must disable the D-cache for reading.'

I want to connect a FPFA to 32bit external bus, Addresses start at 0x6000.0000.

If I only look for the access to the FPGA:  What is the difference between 

A) disabled D-Cache and

B) enabled D-cache and set Memory region in the MPU to sharable, not bufferable and not cacheble?

Disable the D-cache is not an option in my project because this would slow down everything else.

In another thread someone suggested to swap address regions SRAM/SDRAM (0x60000000 <=> 0xC0000000) to change some behaviour.

Does this mean there are some internal attributes bound to the memory regions that cannot be changed via MPU settings?

This is how I would initialize the MPU for access to the FPGA.

 MPU_InitStruct.Enable = MPU_REGION_ENABLE;

 MPU_InitStruct.BaseAddress = 0x60000000;

 MPU_InitStruct.Size = MPU_REGION_SIZE_64KB;

 MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;

 MPU_InitStruct.IsBufferable = MPU_ACCESS_NOT_BUFFERABLE;

 MPU_InitStruct.IsCacheable = MPU_ACCESS_NOT_CACHEABLE;

 MPU_InitStruct.IsShareable = MPU_ACCESS_SHAREABLE;

 MPU_InitStruct.Number = MPU_REGION_NUMBER1;

 MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL0;

 MPU_InitStruct.SubRegionDisable = 0x00;

 MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_DISABLE;

 HAL_MPU_ConfigRegion(&MPU_InitStruct);

[waclawek.jan]

Posted on November 08, 2017 at 11:12

I am by no means a CM7-cache expert, but IMO that's just unfortunately worded sentence intended to say 'you don't want to cache FPGA etc. accesses whatever are the means for it'.

JW

[Gunnar Bohlen]

Posted on November 08, 2017 at 12:15

Thank you,

that is what I assume, bit I would prefer to know it for sure :) (Someone from ST reading this?)

Especially an application note should use a very precise wording to avoid misundersdtanding  - it makes a huge difference disabling d-cache and simply setting up a region in MPU.

It woud be nice to find an application note how to set up the controller correctly for a connection to an FPGA via external bus (which is not memory)

E.g. each read of a status register in the FPGA  should generate an external access.

At the moment I have two problems with CPU=>FPGA Interface:

- there is an access to the FPGA visible via Scope which is not initiated by the CPU (only DMA to write to anSD-c<rd is running)

- in another test I read a status register in the FPGA: in rare cases the result of the read is evaluetad and a cpu-pin is toggled, but there was no physical access on the external bus. (CPU reads from a (disbled) cache?)

[stm322399]

Posted on November 17, 2017 at 10:36

Gunnar Bohlen wrote:

At the moment I have two problems with CPU=>FPGA Interface:

- there is an access to the FPGA visible via Scope which is not initiated by the CPU (only DMA to write to anSD-c<rd is running)

- in another test I read a status register in the FPGA: in rare cases the result of the read is evaluetad and a cpu-pin is toggled, but there was no physical access on the external bus. (CPU reads from a (disbled) cache?)

Caches are usually cleaned before use to prevent random values spawning at power-on to have undesired side effects. This could explain the reported behavior when caches are not cleaned. Occurrences of that kind of bug should be very rare anyway. Make sure cache are correctly cleaned before use.

[Gunnar Bohlen]

Posted on December 07, 2017 at 10:24

Hello,

I initialize the cache once using

SCB_EnableDCache();

SCB_EnableICache();

This also invalidates the cache .

I setup the memory controller for the FPGA (PSRAM interface which seems to give more bandwidth than SRAM), I set up the memory region for the FPGA range for the MPU and -NEVER- access the the FPGA.

All I do is writing dummy-data to the SD-Card.

Is there any reason whe the system sporadically generates accesses to the external memory?

The file on the SD-card seems to be correct, at least all required data transfers to the sd-card seem to be OK (of course I do not know whether the sd-card access causes additional  sporadic accesses to anywhere else).

For a test I disabled the Memory region for the FPGA. If the unwanted access is caused by the CPU, it should now generate a hard fault (access to a non present memory).

Result: I do not get a hard fault. This is for me another indication that the unwanted memory-access is -not- a buggy firmware.

I do not see the memory accesses any more when I stop writing to the SD-card.

[stm322399]

Posted on December 07, 2017 at 20:54

There are so many reason why this could be caused by buggy software even when it does not looks like to be the case.

When the memory region is disabled (how did you do it ?), you told us that no fault is generated, but are there transaction on the external bus ?

If the spurious transaction happens only when SD card is written, it probably means that you will have to look again into the SDIO driver, and double- or triple-check what it is really doing. Did you write that code yourself ? Double-check DMA configuration (DMA might generate bus error without hard fault).

[waclawek.jan]

Posted on December 07, 2017 at 21:09

Also, what exactly are those transaction on the external bus?

IMO, if faulty DMA accesses go to FMC, then running the same code with disabled FMC should lead to DMA error.

JW

[Gunnar Bohlen]

Posted on December 08, 2017 at 09:09

Hello,

with 'disable the memory region' it means I clear the MBKEN (memory bank enable bit).If the CPU does the unwanted memory access, I should now see a hard fault. As I don't get a hard fault I assume the unwanted access is not done by the CPU.Of course I don't see the CS-Signal with the scope any more when MBKEN is 0.

Then I wanted to look for a DMA error from  the memory card access. But I noticed that I get a DMA error for EVERY DMA transaction.(right now I don't remember exactly, I think it was an error related to the FIFO. But this seems to be the normal case because the SDIO has its own fifo and the error can be ignored...)

My main problem was that I implemented a read/write FIFO in the FPGA, and any unwanted access destroyed data in that FIFO. I changed the FPGA-Design into a buffer so the extra bus accesses does not destroy any data anymore.

But I still would like to know what the reason was, but right now I don't have the time anymore for further tests.

I use Keil Middleware for the file system and use uVision (OS=RTOS2/RTX5). Maybe the Keil Middleware uses the SDIO DMA driver from ST?

With the scope I only looked for the Chip select pin/write enable pin. I didn't look for the exact address or data. (4 channel scope)

[stm322399]

Posted on December 08, 2017 at 10:08

Sorry, but DMA error can't be ignored. You must look deeper into the DMA management code.

SDIO is a particular DMA client by the fact that SDIO forces the size of the DMA transfer, that's what is called 'flow controller' in the documentation, make sure that SDIO *is* the flow controller.