团队、
我的客户在使用闪存 API 时遇到异常。
函数"Fapi_issueProgrammingCommand (pu32_dst、pu8_src、u32_num_Bytes、0、0、 Fapi_AutoEccGeneration)"的执行没有任何问题，但在函数结束时的栈恢复过程中 ，会触发„中止(预取)中断"。
您能不能暗示可能的原因？
谢谢！
请查看随附的调试器屏幕截图。 它应该拥有所有相关信息。
您可以在左侧看到状态寄存器。
它们希望写入从地址0x20000开始的16个字节。 转储显示这可以正常工作，但问题仍然如原始帖子中所述。
谢谢！
地狱 FRAM、
对迟迟不能返回表示歉意。
通过查看寄存器内容、我们可以确定以下内容：
首先、我们看 IFSR、它将告诉我们发生的中止类型。 为了确定这一点、我们可以使用 ARM TRM 中的下表。
由于 IFSR 的内容为0x00000409、我们可以看到位10是0b1、位3：0是0b1001。 通过将其与上表[10、3：0]相结合，我们得到的故障状态为0b11001，相当于精确的奇偶校验/ECC 错误。
AIFSR 的内容将告诉我们使用为 AIFSR 定义的位函数发生错误的存储器中的哪一个、如下所示：
由于 AIFSR 寄存器的内容为0x00400000、我们可以确定位23：22是唯一包含内容的字段、并指示错误源位于 ATCM 域或存储器的闪存区域。
最后、我们可以查看 Eh IFAR 寄存器、该寄存器将使用读取的地址、导致错误0x0000000C。 由于 CPU 一次获取64位、因此错误可能以与0x0000000C 关联的32位或相邻的32位为单位(计算 ECC /应用于在64位边界上访问的64位长字)。
鉴于中断矢量通常位于闪存的前20个地址位置、我假设地址0x0000000C 实际上是预取中止矢量的地址。 这将表示有一个中止导致预取中止、然后在预取中止矢量上有另一个中止导致 FSR 被新的中止信息覆盖。 0x0000000C 处的内容会导致该中止是否有任何原因、即、您能否检查在该位置是否已对正确的 ECC 进行了编程？
要找出问题的根本原因(即最初导致中止的问题)、您首先需要解决地址0x0000000C 的预取中止、然后在更正后、您应该看到引发问题的中止源。 或者、我认为第一个中止源的地址可能会在闪存包装程序不可纠正的地址寄存器(FUNC_ERR_ADD、地址为0xFFF87020h)中被捕获、因为它在 CPU 读取前被锁存。
一旦对此进行了调查、并且如果生成中止的原始地址未显示错误的来源、那么我需要了解更多传递到编程函数的值。 具体而言、我们需要确保数据是64位对齐的。 我相信屏幕抓图是这样的、但如果我们知道传入的数据、我们可能能够更有效地跟踪可能发生的情况。
