[参考译文] AWRL1432BOOST-BSD：AWRL1432 毫米波演示在运行一段时间后停止、同时帧启动中断继续

尊敬的 Brent.Lee：

感谢您的查询！
请允许我花一些时间来了解详细信息、然后返回给您！

此致、
Sarvesh

尊敬的  Brent.Lee：

根据这种观察方式、当处理流水线卡在 DPU 阶段内或在其内部同步点周围（最后一个标记保留在）时、是否有理由解释停顿 *_enter 从未达到 *_exit ?

是的,确凿的。 该 SDK 中的每个 DPU 过程函数从调用方的角度来看都是同步SemaphoreP_pend(SystemP_WAIT_FOREVER)的、但在等待 HWA 和 EDMA 硬件回调时在内部阻止开启。

标记保留在的时间 AoA_enter 、TI 是否会建议首先检查：

如果可能,请 AOA_EDMA_WAITAOA_HWA_DOPPLER_WAITAOA_HWA_ANGLE_WAIT在代码中添加类似的子令牌,如 (,,),如果 AoA 仍然是停止点,您将立即知道它是 EDMA 等待, HWA 多普勒 FFT 等待还是 HWA 角度计算等待。

如果 AoA 被绕过并且仍然发生失速、但转向其他 DPU 级（例如多普勒或距离）、TI 是否会将这解释为流水线级问题、而不是单 DPU 特定问题？

是的、我 f 失速是由 AoA 特定 ParamSet 误配置或特定于 AoA 的 EDMA 通道映射错误引起的、绕过 AoA 将完全消除失速。 stall 迁移到其他 DPU 阶段的事实指向所有 DPU 所依赖的共享资源。

此流水线中的所有 DPU 过程函数共享：

• 相同的单个 HWA 实例句柄
• EDMA 控制器实例
• HWA_enableDoneInterrupt() 并 HWA_disableDoneInterrupt() 在每个 HWA 句柄的单个全局注册下运行
  
  
  

在 AWRL1432 毫米波演示参考架构中、是否存在任何已知条件、其中：
   -帧启动中断继续
   -但处理流水线从某个阶段停止返回
   -导致进程令牌不断累积?

无此类已知情况。

TI 是否建议使用首选调试方法来进一步区分失速是：

暂时替换SystemP_WAIT_FOREVER为 AOA 内所有潜在挂起点的超时（例如，10ms）、这会将静默挂起转换为可观察的超时路径。 超时时、转储所有相关状态并返回唯一的错误代码。  您可以尝试这样做、以使故障更容易观察。

此致、
Sarvesh

尊敬的 Sarvesh：

感谢您发送编修。 我们听从您的建议、在 DPU 流水线内添加了更精细的等待点检测、并添加了额外的调试输出以观察共享 HW/EDMA 资源使用情况。

我们添加的内容：

-内部等待点标记:
- range_hwa_wait
- RANGE_EDMA_WAIT
-多普勒_HWAIT_WAIT
-多普勒_EDM_WAIT
- AOA_EDM_WAIT
- AOA_HWA_DOPLOL_WAIT
- AOA_HWA_ANGLE_WAIT
-调试转储字段:
- frameStartInt
- frame_counter
- txTaskCnt
-舞台
- stageFrame
- procToken
- uartToken
- HWA 处理距离/多普勒/AoA 之间的等效性
- EDMA 处理距离/多普勒/ AoA 的等效性
- hwa_enableDoneInterrupt ()/ hw_disableDoneInterrupt () 的最后一个所有者

我们的最新意见如下。

1.非超时运行

在一次运行中、UART 输出停止后、我们仍然可以发出 stat、阶段仍然保持：

- AOA_HWA_DOPLOL_WAIT

观察到的行为：

- frameStartInt 不断增加
- frame_counter 保持冻结
- txTaskCnt 保持冻结
- procToken 不断增加
- uartOverflow=0

这表明在 AoA 等待 HWA 多普勒 FFT 完成时处理流水线卡住。

在另一个非超时运行中、最终可见阶段为 TXTASK_PEND、而：

- frameStartInt 不断增加
- frame_counter 保持冻结
- txTaskCnt 保持冻结
- procToken 不断增加

因此、该运行也停止了、但最后一个全局阶段在我们捕获实际的 DPU 等待点之前被 TX 任务状态覆盖。

2.共享资源确认

在多次运行中、我们的调试转储一致显示：

-距离、多普勒和 AoA 使用完全相同的 HWA 句柄
-距离、多普勒和 AoA 使用完全相同的 EDMA 句柄

例如：

- HWA：sameRD=1 sameRA=1 sameDA=1
- EDMA：sameRD=1 sameRA=1 sameDA=1

因此、这直接确认了您提到的共享资源情况。

3. HWA 完成中断所有权观察

我们还记录了 hwa_enableDoneInterrupt ()/ hw_disableDoneInterrupt () 的最新所有者。

在 AOA_HWAK_PULATE_WAIT 处停止的运行中、观察到的最后一个状态为：

- enOwner=aoa.
- disOwner=CFAR

我们理解、这本身并不证明竞态条件、但它确实可以确认多个 DPU 在相同的 HWA 完成中断注册上下文中运行。

4. timeout-version 运行

然后、我们将这些 DPU 等待点的内部 SystemP_WAIT_FOREVER 替换为基于超时的调试检测。

一次超时运行仍会重现相同的失速签名并保持可观察状态：

-舞台停留在 AOA_HAW_DOPLOL_WAIT
- frameStartInt 不断增加
- frame_counter 和 txTaskCnt 保持冻结
- procToken 不断增加

另一个超时运行导致更难挂起：

-最后一个可见的 UART 输出是 txTaskCnt=12874 frame=12874
-之后,没有更多的 UART 输出出现
- CLI 完全无响应
-甚至按 Enter 键也不会产生提示/响应
-所以我们不能在那个运行中收集 stat

基于这些重复的结果、我们目前的理解为：

-这看起来不像是一个仅限 UART 的问题
-故障在处理管道内是可重现的
-至少一个重复的失速情况点,专门针对 AOA_HWA_DOPLOL_WAIT
- DPU 绝对共享相同的 HWA 和 EDMA 资源
-该问题可能涉及跨 DPU 的共享 HWA/EDMA 使用和/或 HWA 完成中断注册行为

由于我们现在有重复的证据表明这是可重现的并且涉及共享的 HW/EDMA 用法、因此我们希望 TI 在最可能的根本原因方向和最有效的下一个调试步骤方面提供指导。

问题：

1.根据重复观察到、当 frameStartInt 继续增加且 proToken 不断累积时、流水线可能会停滞在 AOA_HWAT_DOPLOL_WAIT 处、TI 是否会将其解释为 HWA 完成事件没有传送回等待的 DPU、或者解释为 DPU 等待错误的同步对象/回调上下文？

2.由于在我们的设置中确认距离、多普勒和 AoA 共享完全相同的 HWA 句柄和 EDMA 句柄、因此 TI 是否发现参考架构中存在一个 DPU 可能影响另一个 DPU 的 HWA 完成中断注册或回调所有权的风险？

3.在 AWRL1432 参考演示流程中、当多个 DPU 按顺序跨帧使用相同的 HWA 句柄时、HWA_enableDoneInterrupt () 和 HWA_disableDoneInterrupt () 是否应该完全安全、或者我们是否应该了解任何已知的限制/顺序依赖关系？

4.当系统卡在 AOA_HWAT_DOPLOL_WAIT 时、TI 最建议接下来转储哪些特定的调试信息？

例如：

- HWA 公共寄存器
- HWA ParamSet 状态
- HWA 中断启用/状态寄存器
- EDMA 传输状态
-挂起中断标志
-信标对象状态
-回叫注册状态

5. TI 是否建议在每个 DPU 阶段之前和之后检查 HWA 完成中断是否仍然启用并且仍然映射到预期的回调？
如果是、是否有任何受 SDK 支持的方法可直接检查该状态？

6.由于一次基于超时的运行导致了 CLI 也变得无响应的更难挂起、TI 认为这一点吗
建议：

-由停滞的流水线引起的更广泛的系统级锁定
-与中断相关的问题
-或者涉及特定 DPU 等待点以外的共享资源的可能死锁?

7.在 TI 视图中、AOA_HWAKE_PUBLIGHT_WAIT 处的重复失速是否建议我们应更多关注：

- AoA 的多普勒触发序列本身
- HWA 完成中断交付
- EDMA 到 HWA 的交互
-还是跨 DPU 共享 HWA 所有权/排序?

8. TI 是否可以向我们指出 SDK 中最可能需要首先对此问题进行审核的源文件或内部函数？
例如、负责以下事项的确切区域：

- HWA 完成中断注册
-回调替换/禁用定序
- AoA 多普勒 FFT 触发路径
-用于 HWA 完成的信标 POST 路径

9.如果 TI 认为这不是预期在参考演示中出现的行为、TI 能否建议一种具体的权变措施或修补方向、我们可以先尝试？
例如：

-保护 HWA 完成中断注册
-重组 DPU 订购
-在每个 HWA_enableDoneInterrupt () 之前添加验证
-在将 HWA 所有权移交给下一个 DPU 之前强制执行明确清理

10.如果有用,我们也可以分享:

-准确的仪器变化
-从非超时和超时捕获的日志运行
-和复制过程中使用的配置文件/配置文件

此问题似乎可以重现、目前正在阻止我们的稳定性验证、因此任何针对 A 的指导都会出现
具体的固定方向将是非常感激的。

此致、
Brent

尊敬的 Sarvesh：

我想跟进我们先前报告的失速问题。

您是否有机会查看我们上次更新的最新观察结果和问题？

在这一点上、问题在我们这边仍然可以重现、并继续阻碍我们的稳定性验证。 特别是,我们已经反复观察到管道停止AOA_HWA_DOPPLER_WAIT,同时frameStartInt继续增加和procToken不断累积。

您能否告知我们、TI 是否有任何进展、或者您是否有建议我们先尝试的下一个调试方向？

例如、了解以下内容会很有帮助：

• TI 目前是否怀疑 HWA 完成中断交付、
• 回叫/注册顺序、
• 跨 DPU 共享 HWA 所有权、
• 或特定于 AoA 的触发/同步逻辑

如果需要、我们还可以以更紧凑的形式再次提供精确的工具更改、日志和复制配置。

如果您有机会更新或建议下一步、我们将不胜感激。

此致、
Brent

尊敬的 Brent：

对延迟回复深表歉意！

我建议 您在下一步中验证失速 DPU 的 HWA 常用寄存器和 ParamSet、因为这些寄存器看起来是导致此失速的最可能原因。

以下是我对您之前的问题的回答：

根据分享的观察结果、听起来 HWA 完成事件并未交付。 我们将需要进一步的信息来区分 HWA 是否已停止、或者中断->回调->信标后链是否已中断。

2.由于在我们的设置中确认距离、多普勒和 AoA 共享完全相同的 HWA 句柄和 EDMA 句柄、因此 TI 是否发现参考架构中存在一个 DPU 可能影响另一个 DPU 的 HWA 完成中断注册或回调所有权的风险？

共享 HWA 句柄 确实会带来 一些风险。  顺序 DPU 架构假设每个 DPU 在下一次启动之前正确清洁、 并且只要 HWA 操作正常完成并且没有损坏、该架构就应该是安全的。  

如果 HWA 操作正常完成、则应该是安全的。

您可以验证 回调执行状态（将一些日志/计数器放在回调内）以及 HWA 通用寄存器和 ParamSet 状态作为下一步。

是的、强烈推荐 、请继续并验证中断是否已启用并正确映射。

6.由于一次基于超时的运行导致了 CLI 也变得无响应的更难挂起、TI 认为这一点吗
建议：

-由停滞的流水线引起的更广泛的系统级锁定
-与中断相关的问题
-或者涉及特定 DPU 等待点以外的共享资源的可能死锁?

仅停止的 DPU 不应影响 CLI 响应。 这可能是由于 CLI 任务的内存被失控操作覆盖、或信标对象未被正确清理、或可能是由于某些未释放的内存分配所导致的。

7.在 TI 视图中、AOA_HWAKE_PUBLIGHT_WAIT 处的重复失速是否建议我们应更多关注：

- AoA 的多普勒触发序列本身
- HWA 完成中断交付
- EDMA 到 HWA 的交互
-还是跨 DPU 共享 HWA 所有权/排序?

首先关注 HWA 完成中断交付、添加一些回调执行日志记录 、这可以帮助确定是否触发中断、但回调失败。 下一步是检查 HWA ParamSet 和常用寄存器、以验证 HWA 的运行。

8. TI 是否可以向我们指出 SDK 中最可能需要首先对此问题进行审核的源文件或内部函数？
例如、负责以下事项的确切区域：

- HWA 完成中断注册
-回调替换/禁用定序
- AoA 多普勒 FFT 触发路径
-用于 HWA 完成的信标 POST 路径

高优先级审计目标：

1. AoA 回调链和 HWA 触发器：  ao2dproc.c- DPU_Aoa2dProc_Process ()、 aoa2dproc.c 第 1703-1705 行（回叫注册）、第 155-160 行（回叫）和第 1768 行（回叫）  HWA_setSoftwareTrigger() 
2. HWA 驱动器中断处理：  hwa.c -WA_enableDoneInterrupt() 和 HWA_disableDoneInterrupt() 实现
3. DPU 时序控制：  dpc.c - CFAR 和 AoA 之间的转换逻辑

9.如果 TI 认为这不是预期在参考演示中出现的行为、TI 能否建议一种具体的权变措施或修补方向、我们可以先尝试？
例如：

-保护 HWA 完成中断注册
-重组 DPU 订购
-在每个 HWA_enableDoneInterrupt () 之前添加验证
-在将 HWA 所有权移交给下一个 DPU 之前强制执行明确清理

请保护 HWA 完成 — 中断注册，并在注册后以及在回调内部登录后添加验证。
还可以在 CFAR 和 AOA 之间进行显式 HWA 复位、以确保 DPU 之间的安全切换。  

10.如果有用,我们也可以分享:

-准确的仪器变化
-从非超时和超时捕获的日志运行
-和复制过程中使用的配置文件/配置文件

现在、我们来验证 HWA 中断状态、回调执行和 HWA ParamSet。 请与我分享您的观察结果 、然后我们可以继续下一步。

此致、
Sarvesh

尊敬的 Sarvesh：

感谢您的指导。

我们遵循您建议的方向并在 CFAR 和 AoA 之间添加了更详细的工具,包括回调执行、HWA 调试/公共状态、共享资源所有权和显式 HWA_RESET () 权变措施。 下面是我们的逐点更新。

1. on 这看起来更像是“ HWA 完成事件未传递回等待 DPU“还是“等待错误的同步对象/回调上下文“

根据当前观察结果、这看起来更像是 HWA 完成事件未传回等待 DPU、而不是回调运行后/信标链失败的情况。

推理：

-停止后,回调计数器停止增加
-我们为 AoA 和多普勒添加了 HWA 回调输入/后计数器
-在正常操作期间,输入== POST
-停止后,这些计数器在重复的 stat 调用中保持完全冻结

到目前为止、我们没有看到“输入回调但信标发布失败“的证据。
然而、我们仍然无法完全区分：

- HWA 本身没有完成
-中断传送未到达回调

2.关于共享同一 Hwa / EDMA 手柄的风险

我们继续确认：

-距离/多普勒/AoA 使用完全相同的 HWA 句柄
-距离/多普勒/ AoA 使用完全相同的 EDMA 句柄

此外、失速不限于单个 DPU：

-一些运行在 AOA_HWAT_DOPLOL_WAIT 停止
-一些运行在多普勒_HWAIT_WAIT 停止

这继续支持共享的 HWA/EDMA/时序控制问题、而不是特定于 AoA 的问题。

3.在顺序 DPU 流程中,HWA_enableDoneInterrupt ()/ HWA_disableDoneInterrupt () 是否安全

我们目前观察到、最后一个中断所有权与停滞的 DPU 保持一致。

AoA 失速情况：

- enOwner=aoa.
- disOwner=CFAR

多普勒失速情况：

- enOwner=多普勒
- disOwner=范围

因此、在更高级别的流程观察中、所有权移交在逻辑上是一致的。
然而,我们还没有直接证据证明驱动程序 API 本身有竞争条件或内部错误。

4.我们在失速期间转储的特定调试信息

我们现在已经分析并观察到：

-回调执行计数器
- HWA 调试/通用寄存器状态
-停止 DPU 参数设置范围
- Shared HWA/EDMA 句柄确认
-中断所有者/启用/禁用计数器
- AoA EDMA/触发路径配置

重要观察结果：

AoA 失速情况：

- STAGE=AOA_HWAT_DOPLOL_WAIT
- DebugHWA param=19 LOOP=1 dmaTrig=0x3 DFE =0x1 swTrig=0x0
- AoA 多普勒配置:
-开始=19
-停止=20

多普勒失速情况：

-阶段=多普勒_HWAIT_WAIT
- DebugHWA param=4 LOOP=1 dmaTrig=0x3 DFE =0x1 swTrig=0x0
-多普勒配置：
-开始=4
-停止=15

因此、失速的 HWA ParamSet 与相应失速 DPU 的 ParamSet 范围相匹配。

5.了解完成中断是否仍然显示为已启用且已正确映射

我们添加并观察到：

-启用/禁用计数器
-最后的所有者
-最后一个手柄
-最后一个信标句柄

在更高层次的观点中、最终所有权与停滞的 DPU 一致。

但是、如果您是指较低级别的驱动程序/寄存器映射状态、我们尚未直接转储驱动程序的内部回调注册状态或中断映射寄存器。

6.在 CLI 也变得无响应的早期较难挂起

我们之前确实观察到了一种较难的基于超时的情况、即 CLI 也变得无响应。
然而、在最近的工具运行中、CLI 通常仍然响应足够、以便在停止后重复进行 stat 收集。

因此、此时我们可以说：

-停止的 DPU 并不总是使 CLI 无响应
-但我们确实看到了至少一个更难的情况

7.我们应该重点关注 AoA 触发路径、HWA 完成中断传输、EDMA 到 HWA 交互还是共享所有权

我们目前的解读是、主要重点仍应放在共享的 HW/EDMA/INTERRUPT / TRIGGER-completion 流水线、而不是 AoA 算法本身。

我们还确认、在当前可重现的 AoA 情况下、AoA 多普勒使用压缩 HOTSIG 路径：

- comp=1
-路径= HOTSIG
- edmaIn.channel=39
- edmaHotSig.channel=40
- dmaTrigSrcChan=0

因此、在此配置中、AoA 多普勒路径不是软件触发路径。 这是热签名/DMA 触发路径。

8.在源文件/内部函数上,我们已经审计到目前为止

我们根据您的建议对以下方面进行了分析和观察：

- aoa2dproc.c
- AoA 回调链
- AoA HWA 等待点
- AoA EDMA 回调
- AoA 多普勒通用配置
- dopplerprochwa.c
-多普勒回调链
-多普勒 EDMA 回调
-多普勒常用配置
- hwa.c
-我们还没有直接转储驱动程序内部回调注册状态,但我们观察到从上层启用/禁用所有权和回调行为
- DPU 测序
-我们观察了 CFAR -> AOA 切换并在那里测试了显式 HWA_RESET () 权变措施

9.关于变通办法/修补方向是否有效

我们在 CFAR_exit 和 AOA_enter 之间实施了显式 HWA_RESET () 权变措施,并进行了 A/B 比较。

观察到的行为：

-每帧都应用了解决方法
- HWA_RESET () 始终返回 0
但这种情况仍然存在

A/B 结果：

-在禁用权变措施的情况下,一次在多普勒 HWAT_WAIT 停止运行
-在启用了变通办法的情况下,系统仍然在 AOA_HWAT_Dopular_wait 停止

因此、显式的 HWA 复位没有消除问题。

10.关于我们是否可以共享工具/日志/配置文件/配置文件

是的、我们可以分享：

-仪器改变
-正常运行和停止运行状态日志
-基线与解决方法 — 在 A/B 日志上
-用于复制的当前配置文件/配置

我们目前的总体解释是：

-这看起来不像一个特定于 AoA 的错误
-这也不像回调执行但信标 POST 失败的情况
-它看起来更像是一个共享的 HWA/EDMA/INTERRUPT /触发器完成流水线问题
-根据运行的不同,它可能表现为在不同 DPU HWA 等待点的失速

如果您同意、我们的下一步可以是深入一层并转储：

-中断状态寄存器
-回叫注册状态
-停顿的 PARAMSet 寄存器内容

此致、
Brent

尊敬的 Brent：

感谢您分享您的观察结果！
回调计数器冻结确认根本不传送 HWA 完成事件。 HWA_RESET() 解决方法不工作表明它也不是简单的 HWA 状态损坏。
您可以转储 HWA 中断状态、回调注册和 ParamSet 寄存器内容。

此外、 请检查 失速操作的 EDMA 通道状态、挂起的传输计数、 并验证 DMA 触发路由配置是否正确。

此致、
Sarvesh

尊敬的 Sarvesh：

感谢您的持续指导。

我们遵循了您的最新建议、并进一步检查了以下方面：

- HWA 中断状态
-回叫注册状态
-停止的 PARAMSet 相关信息在运行时

我们还尝试在运行时转储原始已失速的 ParamSet 寄存器内容。 以下是我们的最新更新。

失速行为与我们之前的观察结果保持一致。 可重现的情况仍然主要出现在 AOA_HWAT_DOPLOL_WAIT 处。 失速后、我们继续观察 frameStartInt 是否保留
frame_counter 和 txTaskCnt 冻结时递增、procToken 不断累积。 这仍然表明帧启动中断继续发生、但处理流水线不再完成
新帧。

失速时的 HWA 状态也与 AoA 多普勒路径保持一致。 在停滞的情况下、我们观察到：

- STAGE=AOA_HWAT_DOPLOL_WAIT
- DebugHWA param=19 LOOP=1 dmaTrig=0x3 DFE =0x1 swTrig=0x0

我们还确认 AoA 多普勒配置保持不变：

-开始=19
-停止=20

因此、失速的 HWA ParamSet 仍然明显位于 AoA 多普勒 ParamSet 范围内。 这与我们之前的解释一致、即在等待 AoA 多普勒时、流水线停滞
完成的 HWA 路径。

然后、我们在失速期间检查 HWA 完成中断状态和回调注册状态。 在失速状态下、我们观察到：

- DebugHwaIrq ret=0 en=1 intNum=66 trigStat=0x1d paramDone=0x1ffffff
- DebugHwaCbReg fn= ARG=

因此、我们目前的解释是：

- Done 中断在驱动程序上下文中仍然显示为启用状态
-回调函数指针仍然存在
-回调参数仍然存在
-回调参数与 AoA 信标句柄匹配

此时、回调注册似乎没有丢失、回调重映射到错误的信标或同步对象也没有。

stall 后的回调计数器行为也与我们之前的运行保持一致。 失速后：

- DebugCb ... AoA=... 停止增加
- DebugAoaCb enter=... POST =... 停止增加
- Enter == POST
-重复的 stat 调用显示这些值完全冻结

因此、这看起来仍然不像“回调已输入、但信标 POST 失败“。 相反、看起来更像是在失速后不再触发回调。

我们还再次确认、当前可重现设置下的 AoA 路径仍然是压缩的 HOTSIG/DMA 触发路径、而不是软件触发多普勒路径。 运行时配置仍显示：

- comp=1
-路径= HOTSIG
- edmaIn.channel=39
- edmaHotSig.channel=40
- dmaTrigSrcChan=0

这也与我们早期的触发仪表一致、在该仪表中、AoA 多普勒软件触发计数保持为零。

根据您的建议、我们尝试将原始停滞的 PARAMSet 寄存器转储 (PARAMn_0 ~ PARAMn_7) 添加到运行时状态路径中。 但是、我们在当前设置中观察到了其他限制：

-在 sensorStart 之前,stat 工作正常
- sensorStart 后,如果 stat 包括原始 ParamSet 寄存器转储,系统会在发出 stat 时立即挂起
-删除原始 ParamSet 寄存器转储后,手动 stat 在 sensorStart 后再次可用

因此、在我们当前的环境中、在运行时直接读取原始 ParamSet 寄存器的内容似乎不安全或侵入式、会干扰正常运行。 目前,这阻止了我们
在 sensorStart 之后在同一运行时路径中安全地收集 PARAMn_0 ~ PARAMn_7。

- HWA 调试/公共状态
- HWA 完成中断状态
-回叫注册状态
-回调计数器
- AoA EDMA/触发器路径配置
-停转 DPU 阶段信息

- AOA_HWA_DOPLOL_WAIT
- param=19
-完成中断仍然显示为已启用
-回电注册仍然存在
-回调计数器冻结
-处理计数器冻结时帧开始仍在增加

我们目前的总体解释仍然是：

-这看起来不像回叫注册丢失
-这看起来也不像回调执行,然后信标后故障
-它看起来更像是 HWA 完成事件从未沿着停止的执行路径实际传递回等待 DPU
-停止的 HWA 上下文仍然对应于 AoA 多普勒参数集范围

此外,CFAR 和 AoA 之间早期明确的 HWA_RESET () 权变措施并没有消除这个问题,现在我们也知道原始运行时 ParamSet 转储本身似乎会破坏系统的稳定性
我们的设置。 因此目前、我们可以在运行时安全地仅观察更高级别的 HWA/中断/回调状态。

如果您同意、我们的下一步可以是调查以下其中一项：

- EDMA 通道状态
-待处理的传输计数
- DMA 触发路由验证
-或一种更保守/更安全的方法,在不干扰运行时执行的情况下捕获暂停的 PARAMSet 寄存器内容

如果有用、我们还可以分享：

-准确的仪器变化
-代表正常运行和停止运行日志
-减少运行时调试输出,保持安全
-用于复制的配置文件/配置

此致、
Brent

尊敬的 Brent：

在失速点、HWA 完成中断状态报告为启用、回调函数指针/回调
参数在可读驱动程序/调试状态下也看起来有效、但 AoA HWA 完成回调计数器不再有效
显著。 根据下面的 HWA 状态、您能否帮助确定 HWA 是否已完成但完成中断/
回调路径未触发、或者 HWA/触发器状态本身是否卡住？
-当前 HWA ParamSet = 19
-触发状态= 0x1d
-参数完成状态= 0x1ffffff
- HWA 完成中断启用= 1
- HWA 完成中断号=66

PARAMSet DONE 状态指示 AOA 参数集已完成处理。 请检查 NVIC 寄存器并验证是否存在任何对应于 66 的挂起中断、还请在 HWA 触发之前转储参数完成状态、以便验证之后是否正在更新完成状态。

您可以在加载符号后尝试在 CCS 中查看这些寄存器。 您可以在所需点设置断点、并通过存储器浏览器查看寄存器。

请验证在失速 DPU 中的 HWA 触发后是否设置了完成状态、以及是否通过 NVIC 验证挂起中断的状态、这将使我们更好地了解流水线在失速条件下的中断位置。

此致、
Sarvesh