[参考译文] TDA4VM：TDA4VM sdk8.0 AVM Project、TIvxCaptureNode 的状态有时似乎总是错误

您好！

您的链似乎在某个位置停止,因为哪个捕获节点正在丢弃所有帧。  请在出现此问题时检查所有节点的状态、并查看其停止位置。  

此致、

Brijesh

您好、 Brijesh：

 当该问题出现(停止)时、如何检查所有节点的状态？

此致  

Hawayi.

嗨、Hawayi、

困难、很可能来自 customAVMNode、您能否在此节点中添加一些日志记录、以了解提交的每个帧是否已 完全处理且没有挂起。  

此致、

Brijesh

您好、 Brijesh：

请提供更多信息、如下所示：

我们添加一个策略:如果没有来自某些频道的图像,并且这些频道上的物理链接被锁定,我们将重置视频捕获。 如果在触发重置捕获策略后、也没有来自某些通道的图像。 然后、将重复执行重置策略、直至所有四个通道的流处理都正常。 然后、有时问题会出现(它会停止)。

并按如下所示查看重新接收视频采集的代码：

FY_S32摄像头服务：：ResetCapture (FY_U32 badChannelMask)
｛
FY_S32 ret =-1；
log_i ("ResetCapture、BAD CHN MASK=%#x\n"、badChannelMask)；

rett = appDeserializerMipiStop ()；//解串器的 mipi 输出

RET = StopCapInst ()；//stop CSI-Rx、这将在 tiovx/kernels_j7/hwa/capture/capture/vx_capture_target.c 上调用 stopCaptureInst

rett = appPowerOffImageSensor (_sensor_name、badChannelMask)；//关闭错误通道的远程串行器和传感器

用户睡眠(1000*1000);

RET = StartCapInst ()；//启动 CSI-Rx、这将在 tiovx/kernels_j7/hwa/capture/vx_capture_target.c 上调用 startCaptureInst

用户睡眠(1000*1000);

rett = appPowerOnImageSensor (_sensor_name、badChannelMask)；//为远程串行器和不良通道的传感器通电

rett = appDeserializerMipiStart ()；//启用来自解串器的 mipi 输出
用户睡眠(500*1000);

appStartImageSensor (_sensor_name、badChannelMask)；//通过配置不良通道的远程串行器开始流传输
返回0；
}

ResetCapture 功能是否有任何问题？

此致  

Hawayi.

您好！

但这似乎是我们开始时遇到的不同问题。 您在前面看到帧丢失问题。 那么帧丢弃问题是否得到解决？  

此致、

Brijesh

您好、Brijesh：

帧丢弃问题未解决。 帧丢弃问题可能与 CameraService：ResetCapture 的调用有关。 我们可以在几天前重复调用 CameraService::ResetCapture 来重现此问题。 但最近我们无法重现这一问题。

您能帮助我们查看 CameraService::ResetCapture 的代码吗？函数的流程是否有任何问题？

此外、我们还会重现另一个问题、即当我们调用 ameraService：：ResetCapture 时、队列计数、出队计数、丢弃计数、捕获节点的错误计数不会以任何方式更改。 当该问题出现时、我们会检查摄像机寄存器是否正在发送帧。 检查正在接收帧的解串器。 我们按如下方式检查 CSI-Rx 寄存器0x4514048、0x4514028。 CSI-Rx 似乎正常接收帧、并且状态寄存器0x4514028中没有 mipi 错误。

此外、我们在另一个项目的 TDA4VE SDK9.2上尝试这些操作、我们发现在调用 StopCapInst ()->stopCaptureInst (vx_capture_target.c)时、stopCaptureInst 显示失败的返回值日志如下：

[220428-17：42：55.243][MCU2_0] 959.287562 s 52242-Handler：Sensor_Remote IM_sensor_CMD_DES_MIPI_STOP
[220428-17：42：55.243][MCU2_0] 959.287636 s：Max96722_MipiStop
[220428-17：42：55.455][MCU2_0] 959.492028 s：[UDMA]
[220428-17：42：55.455][MCU2_0] 959.492070 s：[错误] RX cheardown 超时！！
[220428-17：42：55.455][MCU2_0] 959.492103s：src / csirx_drv.c @行2081：
[220428-17：42：55.455][MCU2_0] 959.492125 s：[ERROR]UDMA RX 通道禁用失败！！
[220428-17：42：55.455][MCU2_0] 959.492158 s：vx_zone_error：[stopCaptureInst：1918] FVID2_STOP 返回失败
[220428-17：42：55.455][MCU2_0] 959.492194s：vx_zone_error：[ownTargetNodeDescNodeControl：1037] SendCommand 失败
[220428-17：42：55.879][MCU2_0] 959.924029s：[UDMA]
[220428-17：42：55.879][MCU2_0] 959.924078 s：[ERROR] RX cheardown timed out！！
[220428-17：42：55.879][MCU2_0] 959.924110 s：src / csirx_drv.c @行2081：
[220428-17：42：55.879][MCU2_0] 959.924132 s：[ERROR]UDMA RX 通道禁用失败！！
[220428-17：42：55.879][MCU2_0] 959.924166 s：vx_zone_error：[stopCaptureInst：1918] FVID2_STOP 返回失败
[220428-17：42：55.879][MCU2_0] 959.924203 s：vx_zone_error：[ownTargetNodeDescNodeControl：1037] SendCommand 失败
[220428-17：42：56.320][MCU2_0] 960.356028：[uDMA]
[220428-17：42：56.320][MCU2_0] 960.356071 s：[ERROR] RX cheardown 超时！！
[220428-17：42：56.320][MCU2_0] 960.356101s：src / csirx_drv.c @行2081：
[220428-17：42：56.320][MCU2_0] 960.356122 s：[ERROR]UDMA RX 通道禁用失败！！
[220428-17：42：56.320][MCU2_0] 960.356155 s：vx_zone_error：[stopCaptureInst：1918] FVID2_STOP 返回失败
[220428-17：42：56.320][MCU2_0] 960.356190 s：vx_zone_error：[ownTargetNodeDescNodeControl：1037] SendCommand 失败

此致

Hawayi.

您好！

不知何故、DMA 通道未完成、以及由于哪个 STOP CAPTURE 无法工作、如果它未 完成、重启也不起作用。  

"[错误] RX 切换超时！！！"

这可能需要在干净清除的 DMA 通道中更改一些驱动程序。 我将在本周分享在 SDK9.2上试用的更改。 您能试一下吗？  

此致、

Brijesh

您好、Brijesh：

是的、我们可以尝试一下。 请在 SDK9.2上分享此更改。 谢谢。

在 TDA4VM sdk8.0上、 为什么调用 stopCaptureInst 时不会出现错误？ 似乎我们需要一种更 巧妙的 StopCapInst 方法、以及如何实现该方法？

此致

Hawayi.

您好！

从 SDK8.0到 SDK9.2、CSIRX 驱动程序没有任何重大变化、所以 您是否确定它在 SDK8.0上运行良好、并且您在 stopCaptureInst 中没有看到任何错误？

此致、

Brijesh

您好、Brijesh：

我们在 TDA4VM sdk8.0 和 TDA4VE sdk9.2上对其进行了测试。  我从两个 SDK 获取了以下版本说明：

PDK_Jacinto_08_00_00_37

pdk_j721s2_09_02_00_30

请重新检查。

此致

Hawayi.

您好！

同样、您是否确定它在  相同场景下可在 pdk_jacinto_08_00_00_37上正常运行？ 使用相同的测试用例？  

此致、

Brijesh

您好、Brijesh：

我已检查 pdk_jacinto_08_00_00_37和 pdk_j721s2_09_02_00_30之间的 pdk/packages/ti/drv/udma 代码 。

在上面、左侧器件为 pdk_j721s2_09_02_00_30、右侧器件为 pdk_jacinto_08_00_00_37。

我将一些日志添加到函数 uDMA_chDisableRxChan 中、如下所示：

udma_printf (drvHandle、"drvHandle->INSTTYPE=%d、%#x、udma_INST_TYPE_NORMAL=%d、udma_INST_TYPE_LCDMA_BCDMA=%d\n"、
drvHandle->INSTTYPE、drvHandle->INSTTYPE、uDMA_INST_TYPE_NORMAL、uDMA_INST_TYPE_LCDMA_BCDMA)；

有关  pdk_jacinto_08_00_00_37和  pdk_j721s2_09_02_00_30的日志如下：

 PDK_Jacinto_08_00_00_37：

drvHandle->INSTTYPE=0、0x0、uDMA_INST_TYPE_NORM=0、uDMA_INST_TYPE_LCDMA_BCDMA=1

 pdk_j721s2_09_02_00_30：

[MCU2_0]  2638.616812 s：drvHandle->INSTTYPE=1、0x1、uDMA_INST_TYPE_NORM=0、uDMA_INST_TYPE_LCDMA_BCDMA=1

因此、区别在于普通 uDMA 在 pdk_jacinto_08_00_00_37上使用、bcdma 在 pdk_j721s2_09_02_00_30上使用。

请检查它。

此致

Hawayi.