Team,
my customer gets an exception when using the flash api.
The function "Fapi_issueProgrammingCommand (pu32_dst, pu8_src, u32_num_bytes, 0, 0, Fapi_AutoEccGeneration)" is executed without any problem, but during stack restore at the end of the function, a „ABORT (PREFETCH) interrupt“ is triggered.
Can you hint at possible causes?
Thanks!
Please find attached a screenshot of the debugger. It should have all relevant information.
You can see the status registers on the left side.
They want to write 16 bytes starting at address 0x20000. The dump shows that this worked, but the problem is still as described in the original post.
Thanks!
Hell FRAM,
Apologies for the delay in getting back.
Reviewing the register contents we can determine the following:
First we look at the IFSR that will tell us the type of abort that occurred. To determine this we can use the following table from the ARM TRM.
Since the content of the IFSR is 0x00000409 we can see that bit 10 is 0b1 and bits 3:0 are 0b1001. Combining this as shown in the table above , [10,3:0], we get a fault status of 0b11001 which equates to a Precise Parity/ECC error.
The content of the AIFSR will tell us which of the memories the error occurred on using the bit functions defined for the AIFSR as shown:
Since the content of the AIFSR register is 0x00400000 we can determine that bits 23:22 are the only field with content and indicate that the source of the error is in the ATCM domain or the flash area of memory.
And finally, we can look at eh IFAR register which will give use the address that was read causing the error which is 0x0000000C. Since the CPU fetches 64 bits at a time, the error may be in the 32bits associated with the 0x0000000C or in the adjacent 32bits (ECC is calculated/applies to the 64bit long word accessed on 64bit boundaries).
Given the interrupt vectors are usually in the first 20 address locations of flash, I assume address 0x0000000C is actually the address of your prefetch abort vector. This would indicate that there was an abort that caused the prefetch abort and then another abort at the prefetch abort vector which caused the FSR to be overwritten with the new abort information. Is there any reason why the content at 0x0000000C would cause this abort, i.e., can you check that the proper ECC is programmed at that location?
To get to the root of the problem (i.e., the issue that originally caused the abort), you would first need to resolve the prefetch abort at address 0x0000000C then, once corrected, you should see the source of the abort the originated the issue. Alternatively, I believe the address of the first abort source might be captured in the flash wrapper uncorrectable address register (FUNC_ERR_ADD at 0xFFF87020h) since it is latched until read by the CPU.
Once this is investigated and if the original address generating the abort doesn't reveal the source of the error, then I would need to know more about the values passed into the programming function. Specifically we need to insure that the data is 64bit alligned. From the screen grab, I believe it is, but if we know the data passed in, we might be able to trace what might be happening more effectively.
