TDA4VE-Q1: capture block at dequeue

Part Number: TDA4VE-Q1
Other Parts Discussed in Thread: TDA4VM

Tool/software:

Hi, TI experts,

SDK version: 10.1

We write an demo: (1280x960@30fps UYVY)capture -> ldc . 

There was an occurrence where, after powering up, the device ran for about 14 minutes and then encountered a capture dequeue failure.

This phenomenon closely resembles a case previously reported. However, since we have already applied the patch from that earlier case, it appears this solution may not be suitable for the ECO board.

We need your further analysis on this issue.

BRs 

regard

  • Hi xie jc,

    What else is running in the system? Is it just capture + LDC? I am just wondering if the this is still causing the same issue..

    Regards,

    Brijesh

  • Yes, just cap+ldc. Indeed, from the perspective of the phenomenon, it is truly the same situation.

  • Hi xie jc,

    Can we disable WDG in the LDC and see if it helps? 

    In order to disable it, please set the flag enableWdTimer in the LDC driver to false and see if it helps. 

    Regards,

    Brijesh

  • We did it, but it still happens.

  • ok, then the issue is due to some other reason. Can we again dump 8 registers from 0x0F008000 offset and check if any of the HW accelerator in stuck?

  • I read 0xf008000 when the block occrur,but system die

    root@j721s2-evm:/# devmem2 0xf008000
    /dev/mem opened.[108571.029655] SError Interrupt on CPU0, code 0x00000000bf000000 -- SError
    [108571.029670] CPU: 0 PID: 217230 Comm: devmem2 Tainted: G           O       6.6.44-ti #1
    [108571.029676] Hardware name: Texas Instruments J721S2 EVM (DT)
    [108571.029678] pstate: 40000000 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    [108571.029682] pc : 0000ffff9fcb3414
    [108571.029684] lr : 0000ffff9fcb57b8
    [108571.029685] sp : 0000ffffd3ef29b0
    [108571.029686] x29: 0000ffffd3ef29b0 x28: 0000ffffd3ef2b80 x27: 0000000000000000
    [108571.029693] x26: 0000000000420000 x25: 0000ffff9fcdf000 x24: 0000ffffd3ef2d78
    [108571.029697] x23: 0000000000000003 x22: 00000000004007a0 x21: 0000ffff9fce6350
    [108571.029702] x20: 0000000000420018 x19: 0000000000000048 x18: 0000000000000003
    [108571.029706] x17: 0000ffff9fcb5770 x16: 000000000041fff8 x15: 0000ffff9fcd8ce0
    [108571.029710] x14: 0000000000000001 x13: 0000ffffd3ef2ad0 x12: 00000000ffffffc8
    [108571.029715] x11: 00000000ffffff80 x10: 000000000000000a x9 : 0000000000000000
    [108571.029719] x8 : 0000000000000040 x7 : 3030306664636639 x6 : 0000000000400358
    [108571.029723] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
    [108571.029727] x2 : 00000000004003d0 x1 : 000000000000000a x0 : 0000000000400580
    [108571.029733] Kernel panic - not syncing: Asynchronous SError Interrupt
    [108571.029735] CPU: 0 PID: 217230 Comm: devmem2 Tainted: G           O       6.6.44-ti #1
    [108571.029739] Hardware name: Texas Instruments J721S2 EVM (DT)
    [108571.029741] Call trace:
    [108571.029743]  dump_backtrace+0x90/0xe8
    [108571.029759]  show_stack+0x18/0x24
    [108571.029764]  dump_stack_lvl+0x48/0x60
    [108571.029769]  dump_stack+0x18/0x24
    [108571.029772]  panic+0x324/0x380
    [108571.029777]  nmi_panic+0x8c/0x90
    [108571.029780]  arm64_serror_panic+0x6c/0x78
    [108571.029785]  do_serror+0x3c/0x70
    [108571.029790]  __el0_error_handler_common+0x40/0xa4
    [108571.029793]  el0t_64_error_handler+0x10/0x1c
    [108571.029796]  el0t_64_error+0x190/0x194
    [108571.029800] SMP: stopping secondary CPUs
    [108571.029808] Kernel Offset: disabled
    [108571.029810] CPU features: 0x0,80000200,28020000,1000420b
    [108571.029813] Memory Limit: none
    [108571.220244] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]---
    
    Memory mapped at address 0xffff9fcdf000.

  • should I read  

    #define CSL_VPAC0_HTS_S_VBUSP_BASE (0x3810000UL) ?

    This is TDA4VEco.

  • Hi,

    Yes, please. 0xf000 is for TDA4VM. So please read 8 registers from 0x381xxx when it gets stuck. 

    Regards,

    Brijesh

  • Hi Brijesh

    The problem reappeared, the register value read is as follows, there is still a scene, if there is anything else you need to see, you can tell me

    root@j721s2-evm:~# devmem2 0x3810000
    /dev/mem opened.
    Memory mapped at address 0xffff7fdd8000.
    Read at address  0x03810000 (0xffff7fdd8000): 0x00000000
    root@j721s2-evm:~# devmem2 0x3810004
    /dev/mem opened.
    Memory mapped at address 0xffffaa429000.
    Read at address  0x03810004 (0xffffaa429004): 0x00000001
    root@j721s2-evm:~# devmem2 0x3810008
    /dev/mem opened.
    Memory mapped at address 0xffffb237f000.
    Read at address  0x03810008 (0xffffb237f008): 0x00000000
    root@j721s2-evm:~# devmem2 0x381000c
    /dev/mem opened.
    Memory mapped at address 0xffffa2f4f000.
    Read at address  0x0381000C (0xffffa2f4f00c): 0x00000000
    root@j721s2-evm:~# devmem2 0x3810010
    /dev/mem opened.
    Memory mapped at address 0xffffbcda7000.
    Read at address  0x03810010 (0xffffbcda7010): 0x00000000
    root@j721s2-evm:~# devmem2 0x3810014
    /dev/mem opened.
    Memory mapped at address 0xffff82ab0000.
    Read at address  0x03810014 (0xffff82ab0014): 0x00000000
    root@j721s2-evm:~# devmem2 0x3810018
    /dev/mem opened.
    Memory mapped at address 0xffffb4c8a000.
    Read at address  0x03810018 (0xffffb4c8a018): 0x00000000
    root@j721s2-evm:~# devmem2 0x381001c
    /dev/mem opened.
    Memory mapped at address 0xffffb71e6000.
    Read at address  0x0381001C (0xffffb71e601c): 0x00000000

  • Hi xie jc,

    As per "0x00000001" value, it seems LDC is still getting stuck. This could be reason why graph is not working and capture is blocking. Are you sure that WDG is disabled for LDC block? If not, can you please disable WDG timeout completely and then try it out? 

    Regards,

    Brijesh

  • Can you give me a patch to disabled WDG? I use VM patch but still occrur.

  • Hi Xie Jc,

    I had used attached patch to disable WDG completely and also have added additional API/Control command to enable and to set its parameters. So can you please apply this patch and see if it works? 

    /cfs-file/__key/communityserver-discussions-components-files/791/0001_2D00_Added_2D00_Interface_2D00_for_2D00_configuring_2D00_WDTimer.patch

    Regards,

    Brijesh

  • Sorry for the delay in replying to you. During this time, I tested the patch that Joe gave me to block wdt from the image, and it didn't appear for a week, thinking that the problem was solved. But today this problem has reappeared.
    1. I want you to check if there is a problem with the patch given by Joe.
    2. In addition, I tried to merge the patch you gave, but found that your patch is a little different from my code, and I can't merge it directly, is this based on TDA4VECO sdk10.1?

    /cfs-file/__key/communityserver-discussions-components-files/791/0001_2D00_imaging_2D00_disable_2D00_ldc_2D00_wdg.txt

  • Hi Xie, 

    But this patch just updates LDC node to process WDG callback. WDG is still enabled in the driver by default. My recommendation is to disable it completely in the driver itself. 

    What all modules are you using in your datapath? If the patch is not getting applied cleanly, can you set htsCfg->enableWdTimer flag to FALSE in all VHWA drivers, rebuild the drivers and then try it out? 

    Regards,

    Brijesh

  • My datapath is capture->ldc->csitx

  • ok, LDC is in the path, can you please disable WDG feature in the LDC driver and then try it out? 

    Regards,

    Brijesh

  • I try to set htsCfg->enableWdTimer flag to FALSE in all VHWA drivers. And testing now

  • ok, thanks, xie jc, will update for your result.