[参考译文] TDA4VEN-Q1：[TDA4VEN][SDK10.1]摄像头流长时间运行后.Fvid2_processRequest 返回失败。

HI TI

Fvid2_processRequest 返回失败-4。

/**\Brief FVID2 API 调用返回错误、设备已在使用中。 示例、  
* 尝试打开驱动程序最多+1次。 显示和捕获驱动程序  
* 仅支持单个打开,而 M2M 驱动程序支持多个打开。 */  
#define FVID2_EDEVICE_INUSE            (-(int32_t) 4)

此致

sungenben

您好、sungenben、

您可以尝试使用以下链接中建议的补丁吗？ 实际上、Linux 上的存储器映射存在问题、因此可能会损坏。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1480108/faq-processor-sdk-j722s-fixes-to-resolve-random-crash-on-j7aen-device-for-the-sdk-upto-sdk10-1

此致、

Brijesh

嗨、Brijesh

应用修补程序后、引导失败。 我们使用2G 内存在我们的广泛.

 如下所示  

此致

sungenben  

尊敬的 Sungenben：

抱歉、此补丁适用于我们有4GB 存储器的 EVM。 因此可能不适用于您在板上使用的2GB 内存。  

好的、什么是 VpacCeVissProcess API？ 我在 SDK 中看不到该 API。  

此致、

Brijesh

嗨、Brijesh  

 我们再次重建、然后再次制作 SD 卡。

还可以、现在可以运行 摄像机可以输出。

我们将尝试测试 修补程序。

此致

sungenben  

谢谢  sungenben  

嗨、Brijesh  

我们已经测试了新的修补程序。

"Fvid2_processRequest return failed -4"仍然发生。

它运行了18个小时。

一旦发生、流就停止了。

此致

sungenben

您好、 sungenben、

很抱歉、哪一个是新补丁？ 什么是 VpacCeVissProcess？ 在已发布的 SDK 中没有名为 VpacCeViss 的内核。  

此致、

Brijesh

嗨、Brijesh  

新补丁如下所示

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1480108/faq-processor-sdk-j722s-fixes-to-resolve-random-crash-on-j7aen-device-for-the-sdk-upto-sdk10-1

VpacCeVissProcess 是我们自己的源代码、它与 TI vpacvissprocess 相同。

我们从已经在大规模产品中进行了测试的 TDA4VL 移植。

此致

sungenben  

您好、 sungenben、

但查看驱动程序代码、我看不到驱动程序返回 device_inuse 错误、尤其是对于 VISS 驱动程序。 另外、在 VISS 节点中、我们没有打印该错误代码、那么您是否已打印此错误代码？ 如果是、您正在打印哪个错误代码？ 它是否从驱动程序 ie fvid2_status 返回？  

此致、

Brijesh

嗨、Brijesh  

是的、我们添加了如下错误代码

此致

sungenben

您好、sungenben、  

在您的代码中,我看到调用 chwaVissRestoreCtx API 时传递给它的 ispObj ,但在我们发布的代码中,这个 API 是用 vissObj 调用的。 那么、 您是否再次更新了这个代码？ VISS 节点中有什么所有变化？  

此致、

Brijesh

嗨、Brijesh

我已经更新了我们的源代码. 请帮助我检查。

e2e.ti.com/.../8154.vx_5F00_vpac_5F00_ce_5F00_viss_5F00_target.c

此致

sungenben  

您好、 sungenben、

好的、我看到了一个方案、因此我们可能会看到这个错误-4。 这是因为 viss 驱动程序中包含以下代码。  我们可以看到驱动程序中有一个繁忙的等待、等待 GLBCE 完成、超时设置为100000。 如果由于某种原因、超时不足、则可以返回此-4错误。  

暂时、您是否可以尝试将 SDK/drv/vhwa_m2mVissPriv.h 中的此超时(GLBCE_CNTX_SAVE_RESTORE_TR_RESPONSE_TIMEOUT_IN_USEC)增加到100000 、然后重新编译 src 并重试？  

            /* Wait for return descriptor in completion ring - this marks transfer completion */
            uint64_t timeout = ClockP_getTimeUsec();
            while(1)
            {
                status = Udma_ringDequeueRaw(instObj->glbceCqRingHndl[VHWA_M2M_VISS_GLBCE_CTX_RESTORE_DMA_CH], &ringPopVal);
                if(UDMA_SOK == status)
                {
                    /* Check TR response status */
                    VhwaAl_Cache_Inv(pTrMem, VHWA_M2M_VISS_UDMA_GLBCE_TRPD_SIZE, CacheP_TYPE_L1D);
                    trRespStatus = UdmaUtils_getTrpdTr15Response(pTrMem, 1U, 0U);
                    if(CSL_UDMAP_TR_RESPONSE_STATUS_COMPLETE != trRespStatus)
                    {
                        GT_0trace(VhwaVissTrace, GT_ERR, "Failed TR Response for GLBCE ctx restore\n");
                    }
                    break;
                }
                if((ClockP_getTimeUsec() - timeout) > GLBCE_CNTX_SAVE_RESTORE_TR_RESPONSE_TIMEOUT_IN_USEC)
                {
                    GT_0trace(VhwaVissTrace, GT_ERR, "Ring dequeue GLBCE ctx restore Timeout failure\n");
                    break;
                }
            }

此致、

Brijesh

嗨、Brijesh  

感谢您的答复。

我们将设置 #define GLBCE_CNTX_SAVE_RESTORE_TR_RESPONSE_TIMEOUT_IN_USEC (10000U)  

然后再次测试。

此致

sungenben  

嗨、Brijesh  

我们测试了几天、但没有再次发生。流式传输始终在 运行  

此致

sungenben