[参考译文] AWR1642：AWR1642：DSP 未检测到来自 MMIC 的中断

您好！

您需要提供有关该实验设置的更多信息。

如何探测这两个中断？ 我想您正在控制 DSP 的 GPIO 之一。

当您看到线性调频脉冲中断(GPIO 切换)缺失时、DSS 中的线性调频脉冲中断计数是否不匹配？

此致、

Jitendra

Jitendra、您好！

下面列出了您的问题的答案。

〇How 您是否探测这两个中断？ 我想您正在控制 DSP 的 GPIO 之一。

   是的。  

  我通过 DSP 操作 GIO 并将 GPIO 切换为高电平/低电平。

每次调用线性调频脉冲回调函数时、GPIO 控制都会将 GPIO_0切换为高电平/低电平。 此外、每次回调函数完成时、都会切换 GPIO_1的高电平/低电平。

〇When 您看到线性调频脉冲中断(GPIO 切换)缺失、DSS 中的线性调频脉冲中断计数是否不匹配？
→是。

  如果缺少线性调频脉冲中断、DSS 中的线性调频脉冲计数将小于设置的值。

谢谢、此致、

Takahashi。

我对 DSS 上的代码有所了解。 您是否观察到即使没有 GPIO 控制代码也缺少线性调频脉冲中断？ 与默认的 MMW 演示应用一样、我们不会观察到任何缺失的线性调频脉冲中断。

您可以尝试从 MSS 写入以下寄存器值、该 MSS 将 ADC_VALID 连接到 GPIO_0线路。

REG32_WRITE (0xFFFFFF8、0x83E70B13)
REG32_WRITE (0xFFFFFFFC、0x95A4F1E0)
REG32_WRITE (0xFFFFFFE260、0x6101)
REG32_WRITE (0xFFFFFFE 270、0x30)
REG32_WRITE (0xFFFFFFEA04、0x44)
REG32_WRITE (0xFFFFFF8、0x0)
REG32_WRITE (0xFFFFFFEBFC、0x0)

通过此更改、您无需从 DSS 切换 GPIO、因为它现在已连接到 ADC_VALID 中断线路。 ADC_VALID 与到 DSS 的线性调频脉冲中断相同。

此致、

Jitendra

Jitendra、您好！  

我尝试了您的回复中的内容。
结果是 MSS 检测到中断、但 DSS 未检测到。

从这个结果来看、中断似乎在 DSS BIOS 中被暂时禁用。
您是否知道中断为什么停止？

谢谢、此致、

Takahashi

你好 、Takahashi-San、

我建议从 DSS 禁用 GPIO 控制并从执行 ADC_VALID 到 GPIO_0引脚连接的 MSS 启用上述寄存器写入。 因此、在外部、当您在 GPIO_0引脚上进行探测时、您可以看到线性调频脉冲中断。

现在、根据您最新的图片、绿色图意味着什么？ 是在 DSS 控制/切换 GPIO 时吗？ 您在此图中为 MSS 和 DSS 图示探测了哪个引脚？

另一方面、DSS 不应错过其内核上执行信号处理的任何线性调频脉冲中断、因为 MMW 演示提供了在运行 SYSBIOS 进行处理时从不错过任何线性调频脉冲中断的参考。

此致、

Jitendra

Jitendra、您好！

绿色波形是由 DSS 控制的 GPIO_21波形。
此 GPIO 的控制内容与之前相同、每次调用线性调频脉冲回调函数时切换为高电平/低电平。

从 DSS 控制 GPIO 的原因是、您不知道 DSS 何时错过了线性调频脉冲中断。 换句话说、如果不监控 DSS、您将不知道错过中断的位置。

红色波形是使用答复内容在 GPIO_0上测量的波形。 因此、我认识到该波形与 MSS 检测到的中断同步。

在您的回复中、"DSS 不应错过其内核内部的任何线性调频脉冲中断来进行信号处理"是指监控 DSS 内部的计数器？

谢谢、此致、
Takahashi

Jitendra、您好！

使用以下设置执行测量。

-来自 DSS 的所有 GPIO 控制无效。

设置为从 MSS 将 GPIO_0与 ADC_VALID 同步。

因此、GPIO_0没有问题、但 DSS 线性调频脉冲中断计数器小于指定的数字。 因此、DSS 错过了中断。

谢谢、此致、
Takahashi

Takahashi-San、您好！  

错过任何线性调频脉冲中断时、是否可以在 DSS 中执行断言并通过 UART/CAN 在芯片外部发送故障日志？ 在这个设置中、您是否可以在没有任何 JTAG 连接的情况下尝试实验？

与毫米波 SDK 的 mmw 演示一样、DSS 在进行信号处理时可以检查是否缺少任何线性调频脉冲中断。 在默认的 MMW 演示中、我在 DSS 结束时看不到任何缺失的线性调频脉冲中断

您需要检查在 rlSetProfileConfig API 中是否为 RadarSS 配置了足够的线性调频脉冲空闲时间。 DSS 应在此时间内完成处理(1-D FFT：线性调频脉冲间时间)、以便在到达下一个线性调频脉冲中断时可以自由地执行该中断。

在 DSS 应用程序中、任何线性调频脉冲/帧中断都设置为更高优先级的中断、因此即使 DSS 在某些任务中占线、它也会在到达时切换到中断上下文(线性调频脉冲中断)。

此致、

Jitendra

您好 Jitendra

即使软件被写入 ROM 并启动、也会发生这种情况。

您的看法似乎与我的看法不同。 让我检查一下内容。
我们使用的软件是演示软件的修改版本。
MMIC 不是以固定的时序启动、而是每次从 ARM 触发(定时器事件或 ARM 接收到的外部触发器)时启动。
当外部触发器出现问题时、会发生该错过的线性调频脉冲中断。
条件是
1. 1D-FFT 已完成，即线性调频脉冲中断处理已正常完成。
2.1在1D-FFT 之后的帧间处理()过程中会错误地激活外部触发器、并且会激活 MMIC。
当满足上述条件时，就会出现此问题。

我意识到线性调频脉冲中断的优先级高于产生的任务。
那么、我想知道的是、DSP 程序中是否有一些东西会延迟中断。
例如
・Ω 重堆叠负载
当・特定的汇编器代码时、μ C 中断被延迟
μ・中断在异常处理过程中停止。
等等

谢谢、此致、
Takahashi

Takahashi-San、您好！  

我了解到您正在尝试使用外部脉冲触发帧、并且您已在 rlSetFrameConfig API 中将 triggerSelect 选项设置为(0x0002 HWTRIGGER)。

因此、如果在当前帧运行期间有任何脉冲到达、则接受 HW 脉冲的 RadarSS 不会触发下一帧。

即帧由多个线性调频脉冲和更高的帧空闲时间组成；新的 HW 脉冲必须在帧空闲时间之后给出。

如果在此帧时间内给定了下一个脉冲、则它不会触发任何新的帧(或线性调频脉冲)。 因此、期望 DSP 接收线性调频脉冲中断超出范围。

现在、您需要检查外部触发脉冲相对于帧时序的时序。

此致、

Jitendra

Jitendra、您好！

BSS 由软触发器操作。
MSS 接收到外部触发信号。 MSS 在接收到外部触发器时调用 rlSensorStart ()。
因此、rlSetFrameConfig API 设置为软触发。

 发生问题时的外部触发时序晚于 BSS 中设置的帧时间。
*在 BSS 中设置的帧时间与 DSS 处理周期时间不同。 DSS 帧处理时间的设置时间长于 BSS 帧时间。
因此、BSS 会检测 MSS 的软触发、无线电波会按照规定发射样本和线性调频脉冲。

这与之前 MSS 中测量的 ADC_VALID 正常但 DSS 错过了线性调频脉冲中断的结果一致。

谢谢、此致、
Takahashi

Takahashi-San、您好！  

• 您能否将 DSS 应用程序实现方案与用于中断(帧/线性调频)处理程序实现的 mmw 演示 DSS 应用程序进行比较？
• 当您在 rlSetFrameConfig 中使用单帧设置并从 MSS (外部触发器)执行帧触发(rlSensorStart)时。
• 如何使用连续组帧模式而不是 HW 触发器(来自 MSS rlSensorStart)、即无限次 帧数位于 rlSetFrameConfig API 中？ 您是否看到此设置的行为相同？
• 在 DSS 应用程序中、在重新触发下一帧之前、是否等待帧开始或结束异步事件消息？ 如果是、则删除 DSS 应用程序上的等待。
• 并将线性调频脉冲中断处理程序函数中的代码保持在最小值。
• 在 DSS 应用程序中、如果有任何 while 等待循环、则确保 在 while 循环中有 Task_sleep、以便在中断到达时发生任务上下文切换；理想情况下、中断上下文是任务优先级最高的、因此应切换到中断处理程序。

此致、

Jitendra

Jitendra、您好！

我对以下内容有疑问：
在 DSS 应用程序中，如果有任何 while 等待循环，则确保在 while 循环中有 Task_sleep，以便在中断到达时发生任务上下文切换；理想情况下，中断上下文是任务优先级最高的，因此应切换到中断处理程序。”

问题：

• 这是否意味着如果 while 循环中没有 TaskSleep ()，则切换上下文中将会有延迟？
• while 循环中的处理优先级是否临时增加以加快处理速度？
• 如果上述为是、是否不仅发生在 while 循环中、还发生在 for 循环中？

谢谢、此致、
Takahashi。

*如果应用程序在某个无限等待 while 循环中被阻止、则 TaskSleep 主要需要切换到另一个并发运行任务(较低或较高)。 否则、SysBIOS 将负责切换上下文本身、它会观察一些空闲任务。

*根据 MMW 演示、进行处理的任务已经是最高的。 因此它不会影响该任务的处理速度。

*阻止循环内的 TaskSleep 适用于和同时适用于这两种情况。

让我来回顾一下这个问题-

您曾说过、MSS 错误地发送额外脉冲以触发 sensorStart、当它发送该信号时、什么是 DSS 状态？ 在这段时间内、它是进行2D 还是3D FFT 或其他处理？

理想情况下、新帧应仅在最后一帧处理完成后才开始。

触发 sensorstart 事件是否有任何特定用途、但为什么不能使用无限帧来避免从 MSS 触发(调用 sensorStart API)。

MMW 演示在调用传感器启动时所做的其他操作是、它首先与 DSS 同步(意味着向 DSS 发送一条邮箱消息、以便先执行所有预处理、然后只有 MSS 通过邮箱将 SensorStart 消息发送到 RadarSS。

您需要考虑 DSS 状态(如果不应执行最后的帧处理)和当前帧触发的预处理时序、以避免这种类型的错误。

此致、

Jitendra

Jitendra、您好！  

答案如下所述。

您的问题

• "您说 MSS 错误地发送额外脉冲以触发 sensorStart、当它发送该信号时、什么是 DSS 状态？ 在这段时间内、它是进行2D 还是3D FFT 或其他处理？ ""

答案

• 是的。 DSS 正在处理数据。 正在执行的处理是跟踪和分组等处理。

您的问题

• "是否有任何特定的目的触发 sensorstart 事件、但为什么不能使用无限帧来避免从 MSS 触发(调用 sensorStart API)。 ""

答案

• 由于系统设计、inifinite 帧无法使用。

我的问题：

• 无论优先级如何、为何任务切换都需要 Task_sleep？ BIOS 是否有时禁用中断？
• DSS 帧处理完成后、"当前帧触发的预处理时序"是否为时序？
• 如何将中断函数从上下文切换到处理程序？

谢谢、此致、

Takahashi

Takahashi-San、您好！

理想情况下、新的帧触发只应在最后一帧的所有处理完成后发生、否则 DSP 将无法处理来自下一帧的线性调频脉冲(因为它正忙于最后一帧的处理)。 因此、您需要确保下一个 sensorStart 触发器必须在最后一个帧处理结束后到达。

* BIOS 在应用程序禁用中断 b 默认值之前不会禁用该中断 b。

*是的、它只需要在最后一个帧处理完成时触发。

*理想情况下、中断上下文是最高优先级、因此它应切换到独立于任务优先级的处理程序。

我要求遵循上述条件、以遵守时间限制。  

在 MMW 演示中、我检查了几乎相同的情形、但我设置了长帧计数、但将帧周期设置得非常短、因此下一个帧中断在 DSP 完成最后一个帧处理之前到达。 因此、在这种情况下、它会命中下一个线性调频脉冲中断处理程序并达到断言条件(由于最后一个帧处理未结束)。

此致、

Jitendra