2024-04-05 01:13 PM
Hi,
I am using the RAMECC_ErrorCount example to understand the working.
/* Analyse all memory */
for(Count = 0; Count < (MEMORY_SIZE / INC_OFFSET); Count++)
{
CurrentData = *(__IO uint32_t *)(MEMORY_BASE + (Count * INC_OFFSET));
}
* @brief Single or double ECC error detected callback.
* @PAram hramecc : RAMECC handle
* @retval None
*/
static void RAMECC_DetectErrorCallback(RAMECC_HandleTypeDef *hramecc)
{
RAMECC_Error_Detected++;
BSP_LED_On(LED2);
}
I get the first callback with FAD as 118 and the value of count is 234 at this point.
The FAD address can be derived to 0x2400 0000 + 118 * 8 = 0x2400 03B0.
But the address from which the last value read is: 0x2400 0000 + 234 * 4 = 0x2400 03A8.
There is a difference of 8 bytes. If I introduce a memory barrier instruction after the read operation (line 4), the callback will occur when the count is 232. Why does the callback report an address which is not even read ?
Please note that this example enables the cache by default. I tried by disabling the cache and then the count value and the FAD matches. ie, I get count as 236 when FAD is 118.
0x2400 0000 + 236 * 4 = 0x2400 03B0.
Could you please help me to understand this ?
2024-04-05 02:33 PM
When you disable the cache, memory accesses become more predictable, as there are no caching effects to contend with. This results in consistent behavior where the count value matches the expected FAD.
2024-04-06 04:28 AM - edited 2024-04-06 04:35 AM
Thank you for your reply @liaifat85 .
I understand that this is due to enabling cache, but I am trying to understand it.
Could you please explain me how enabling cache is affecting this ? FAD reports an address which is not even read.