[参考译文] PROCESSOR-SDK-J721S2：将 CSIRX CRC 错误与特定帧相关联

您好、Nikita、

那么、是否有任何可靠的方法可以知道返回的特定帧缓冲区对应于不稳定的帧？

不、因为在当前驱动程序中、错误回调和帧结束回调都 是异步回调、所以很难做到这一点。  

(1) 回电 订单是否得到保证？ 在收到有关接收的通知后、关于接近帧末尾的错误的通知不能发生吗？ 或者、在收到关于前一帧的通知之前、不能在接近帧起始位置收到关于错误的通知？

否、根据错误生成的不同、可能 无法保证订单。  

(2) 如果同一 CSIRX 实例接收到多个帧（用于不同的 VC）、如何知道收到哪个特定的帧时出错？

可能、根据回调时间戳和帧自己的时间戳、您可以使用 ECC 错误标记帧。  

此致、

Brijesh

可能、根据回调时间戳和帧自己的时间戳、您可以用 ECC 错误标记帧。  [/报价]

我认为在通过 4 通道 GMSL 链路接收的典型多摄像头中、帧交错、所有通道的时间戳几乎相同。

因此，看起来唯一可实现的方法是 — 注意错误回调的时间戳，并假设来自任何信道且时间戳介于 T 和 T+FRAME_TIME 之间的任何帧都中断。

一点都不好

硬件是否确实无法通知 DMA 机器发生了错误 — 因此 DMA 机器可以将描述符标记为不稳定？  看起来这是唯一可靠的方法...

我认为 CSIRX 中没有任何方法可以识别生成错误事件的信道。

我仍然在寻找两个选项来更好地检测坏帧:

(1) CSIRX_ERROR_DEBUG 寄存器 — 不能以某种方式使用其中的信息？  虽然看起来它是 不可避免地 raty racy  发生的第二个错误之前发生的第一个由软件处理。

(2)“无错误旁路模式“-这不能用于在错误后强制停止接收帧、从而在 DMA 级别将具有 CRC 错误的帧转换为“短帧“？  尽管这不会在最后一行中捕获 CRC 错误... 但是、最后一行是嵌入行、由 CRC 本身保护、因此也许忽略最后一行中的 CRC 错误不是大问题。

(1) CSIRX_ERROR_DEBUG 寄存器 — 无法以某种方式使用其中的信息？  虽然看起来它是 不可避免地 raty racy  发生的第二个错误之前发生的第一个由软件处理。
[/报价]

是的、没错、该寄存器会报告 生成此错误的通道 ID 和数据类型、但这 也是异步的、具体取决于是否有错误回溯。  

(2)“无错误旁路模式“-这不能用于强制在错误后停止接收帧、从而在 DMA 级别将存在 CRC 错误的帧转换为“短帧“？  尽管这不会在最后一行中捕获 CRC 错误... 但是、最后一行是嵌入的行、由 CRC 本身提供保护、因此忽略最后一行中的 CRC 错误可能不是大问题。

是的、可以使用、但 这是您想要做的吗？

此致、

Brijesh

[/quote]

这是您要做的事

我想将坏帧标记为坏帧、将好帧标记为好帧。  我真的很惊讶的事实,没有有效的支持这一点,因为看起来像随机比特翻转在通道不是那么罕见（我见过一些）。

到目前为止,我建议架构忽略 GMSL（隧道模式）级别的 CRC 错误,并处理 CSIRX 级别的 CRC 错误 — 正是因为它不可能将错误映射到传输中的帧,但 在接收时可能。  CSIRX 不支持这种映射是令人惊讶和困惑的。 如果这只是一个驱动器限制比我准备好提高驱动器...  但看起来 CSIRX 硬件无法以可用的方式传递错误信息？？？  如果是这种情况,它看起来像一个主要的设计缺陷:(

我想将坏帧标记为坏帧、将好帧标记为好帧。  我真的很惊讶的事实,没有有效的支持这一点,因为看起来像随机比特翻转在通道不是那么罕见（我见过一些）.[/报价]

嗯、 对驱动程序没有支持、但 HW 支持通过在寄存器的 VC 和 dt 字段中注册它。 您需要读取它们以确定哪个通道错误并将其标记为良好/不良。

到目前为止,我建议架构忽略 GMSL（隧道模式）级别的 CRC 错误,并处理 CSIRX 级别的 CRC 错误 — 正是因为它不可能将错误映射到传输中的帧,但 在接收时可以。  CSIRX 不支持这种映射是令人惊讶和困惑的。 如果这只是一个驱动器限制比我准备好提高驱动器...  但看起来 CSIRX 硬件无法以可用的方式传递错误信息？？？  如果是这种情况,它看起来像一个主要的设计缺陷:(

我 不认为这是一个设计缺陷,它在硬件支持..  

此致、

Brijesh

[/quote]

HW 通过在 register

您是指 CSIRX_ERROR_DEBUG 寄存器吗？

我是否正确理解在检测到错误时写入该寄存器、覆盖那里的任何以前的值？

从错误发生的时刻到  软件错误处理程序读取此寄存器的时刻之间存在不可避免的延迟。 如果在此延迟内再次发生一个错误，则有关第一个错误的信息将被覆盖 — 除非硬件支持此信息的某些队列。 是否支持类似的功能？

不过、 也许您可以要求熟悉此 IP 的硬件工程师、是否有办法将错误信息传递到发送了不稳定数据的 DMA 流、从而在 DMA 传输状态中作为错误标记结束？ PSIL 是否支持此类通知？ 这实际上是常见硬件处理错误的方式 — 例如，任何网络适配器通过连接到接收帧的状态字段传递接收错误。  

在安全环境中、错误信息的丢失显然比提供误报更糟糕... 因此、使用只能记住一个错误的寄存器来标记坏帧并不是一种安全的实现方式。  相反、必须将错误导致的任何帧标记 为不可靠。

您是指 CSIRX_ERROR_DEBUG 寄存器吗？

我是否正确理解在检测到错误时写入该寄存器、覆盖那里的任何以前的值？

是的、这是我之前提到的寄存器。

从发生错误的时刻到  软件错误处理程序读取此寄存器的时刻之间存在不可避免的延迟。 如果在此延迟内再次发生一个错误，则有关第一个错误的信息将被覆盖 — 除非硬件支持此信息的某些队列。 是否支持类似的任何内容？

否、HW 不支持任何此类排队。

不过、 也许您可以询问熟悉此 IP 的硬件工程师、如果有某种方法可以将错误信息传递到发送了不稳定数据的 DMA 流、从而在 DMA 传输状态中作为错误标记结束？ PSIL 是否支持此类通知？ 这实际上是常见硬件处理错误的方式 — 例如，任何网络适配器通过附加到接收帧的状态字段传递接收错误。 

我认为这一信息没有被传递给 PSIL、 但仍将确认相同的信息。  

此致、

Brijesh