专家你好
我们收到来自 IAST 的问题，他们报告 M7 应用程序报告了FR[AIBSEF] 错误。他们使用的是 RTD4.0.2。
根据 S32G3 RM 的说法，当 AHB 突发大小大于 bufxCR [ADATSZ] 中的预取大小时，AIBSEF 就会被触发，我检查过他们的 BUF3CR [ADATSZ] 是 0x80，这是 QSPI 支持的最大大小（1024 字节）。您知道如何检查 S32G 寄存器中的 HBUSRT 大小吗？能否请您也就此问题发表一些意见？
我还在 S32G RM 中发现了另一个令人困惑的地方，即 AHB 读取不支持 WRAP* 事务，这是否意味着 G3 实际上不支持 HBUSRT？如果是，FR[AIBSEF]的根本原因是什么？
我在 QSPI 中没有看到设置 HBURST 和 HSIZE 的地方。但是从我的角度来看，最大突发量 = 16，最大 Hsize = 64 位 = 8 字节。因此，AHB 事务的最大突发总大小 = 16 x 8 = 128，不能大于 1024。我没有看到驱动程序处理 FR[AIBSEF] 位。请将 AIBSEF 位出现时 QSPI 的所有寄存器和 QSPI 配置文件发给我，我将试着查看是否能发现任何问题。
顺祝商祺！
Nhi
这是从客户处收到的寄存器
从你的图像来看，AHB 缓冲区的配置如下：
遵循 RM 中的主 ID 表：
如果用户使用 M7，似乎所有事务都会被路由到缓冲区 3，因为主 ID 与其他缓冲区不匹配。但缓冲区 3 的配置是 1024，所以我不明白为什么他们能得到这个位。
但是，我认为他们可以尝试更改缓冲区配置，以查看与缓冲区0、1、2匹配的缓冲区大小为0且序列ID表示16字节的数据。
如果他们使用多个内核，请尝试将每个主 ID 路由到不同的缓冲区。例如CM7_0 至缓冲区 0，CM7_1 至缓冲区 1，...
在执行新的 AHB 事务之前，请尝试检查这些位是否被提升。
我们收到客户的反馈，在阻止 A53 内核访问后，问题消失了，因此问题可能是由 A53 内核的投机访问引起的，我不知道为什么这种访问会导致AIBSEF 错误。我想确认的另一个问题是：
S32G3 QSPI 支持 AHB 突发功能吗？正如我在之前的评论中提到的、
在 RM 中，QSPI 不支持 AHB warp 功能，但也有一节介绍了 AHB burst 功能，这让我很困惑？能否请您帮忙确认一下这项功能？
从 RM 中，我了解到 AHB 支持 2 种类型：WRAP 和 INCR。但 S32G3 只支持 INCR。 HBurst 和 Hsize 无法在 QSPI 中配置。它们在 Core 文档中定义，并在启动时配置。
在客户的案例中，他们为核心 A53 配置了核心主 ID 0、1、2，分别为缓冲区 0、缓冲区 1、缓冲区 2，缓冲区大小为 0，因此用于与突发大小进行比较的数据大小是在序列 Id 中配置的数据。就他们而言，我看到序列中的数据大小为16字节，如果启动时配置的突发大小大于此值，则可能会发生此问题。