Cortex-M7 m25q-driver cache coherency Topic is solved
Posted: Thu Jun 15, 2017 8:08 pm
Hello again,
Here I am with another cache coherency problem on the M7-platform.
The m25q-driver in the ChibiOS trunk utilizes QSPI. The problem is that DMA is used for the transfer and of course on the M7-platform the cache coherency problem pops up again
. The mayor problem I had was:
- The program hangs in "m25q_poll_status" because the "sts" buffer is never invalidated so the result of the QSPI-receive operation is never seen by the CPU.
I have attached a modified version of the m25q-driver with fixes for the problem. There are only a couple things I am not sure of:
- Are these changes compatible with other platforms?
- In the function "m25qStart" the device ID is read twice for confirmation, but the first time the ID is stored in the "M25QDriver *devp". Does this need to be invalidated also, because will it be cached? Also it probably isn't 32-bit aligned in ram.
Here I am with another cache coherency problem on the M7-platform.
The m25q-driver in the ChibiOS trunk utilizes QSPI. The problem is that DMA is used for the transfer and of course on the M7-platform the cache coherency problem pops up again
. The mayor problem I had was:- The program hangs in "m25q_poll_status" because the "sts" buffer is never invalidated so the result of the QSPI-receive operation is never seen by the CPU.
I have attached a modified version of the m25q-driver with fixes for the problem. There are only a couple things I am not sure of:
- Are these changes compatible with other platforms?
- In the function "m25qStart" the device ID is read twice for confirmation, but the first time the ID is stored in the "M25QDriver *devp". Does this need to be invalidated also, because will it be cached? Also it probably isn't 32-bit aligned in ram.