• State
  • Replies 11 replies
  • Subscribers 99 subscribers
  • Views 126 views
  • Users 0 members are here
Support feedback
Options
Options
Related

AM62A7: LDC watchdog timeout causes application to wait indefinitely when VPAC LDC stops processing frames

Ninh Nguyen
Prodigy 200 points

Part Number: AM62A7

Hi TI experts,

We are testing our application using the TI VHWA M2M LDC driver and have observed an issue when the LDC HTS watchdog fires. After the watchdog timeout, the LDC stops making forward progress while processing a frame, and the application waits indefinitely for the request to complete.

The following observations were collected after reproducing the issue.

Evidence

The HTS watchdog is enabled for the LDC and configured in the default 64K timeout mode (WDTIMER_MODE = 0), consistent with the stock TI implementation.

After the watchdog timeout, the LDC register snapshot is:

 
CTRL           = 0x00020217
ERR_STATUS     = 0x00000000
FR_PDFTCH      = 0x006CD0E0
FR_MDFTCH      = 0x0001D100
DEBUG_STATUS   = 0x00031806
 

Additional observations

Before the timeout

  • WDTIMER_EN = 1
  • WDTIMER_MODE = 0 (64K cycles)

After the timeout

  • WDTIMER_EN is cleared by the driver, confirming that the watchdog interrupt has been serviced.
  • CTRL.BUSY remains set.
  • FR_PDFTCH and FR_MDFTCH remain unchanged over multiple reads spanning several seconds.

HTS scheduler status:

 
HWA2 Scheduler = 0x00000403
  SCH_EN = 1
  PAUSE  = 0
  STATE  = 8
 
  • ERR_STATUS remains 0x00000000.
  • No Frame Done interrupt is generated after the watchdog timeout.

Based on these observations, the LDC appears to stop making forward progress after the watchdog timeout while remaining BUSY, and the current request never completes.

For reference, we have attached a sequence diagram illustrating the observed execution flow in both the normal case and the watchdog timeout case.

Questions

1. Expected driver behavior after a watchdog timeout

After an LDC watchdog timeout, what is the expected behavior of the VHWA M2M LDC driver?

Should the driver:

  • Complete the current request with an error status and allow the application to continue,

or

  • Require the application to close and recreate the Fvid2 handle before submitting new requests?

If the driver is expected to complete the pending request, is the current implementation of vhwaM2mLdcIsr() correct, or is additional error-handling logic required?

2. Finite timeout for Fvid2_processRequest()

Is using a finite timeout with Fvid2_processRequest() officially supported and validated for the VHWA M2M drivers?

The implementation appears to support this by returning FVID2_EAGAIN when SystemP_TIMEOUT occurs. However, all TI sample applications use FVID2_TIMEOUT_FOREVER.

Can a finite timeout be safely used as a recovery mechanism for watchdog-related hangs?


image.png


  • 0
    TI__Guru 62430 points

    Hi Ninh,

    We'll be looking into this issue and try to get back as soon as possible.

    Regards,

    Jianzhong

  • 0 in reply to Jianzhong Xu
    TI__Guru 62430 points

    Hi Ninh,

    I'm still discussing internally about this. You'll probably need to use an external watchdog timer for this purpose.

    Give me a few more days.

    Thank you for your patience.

    Regards,

    Jianzhong

  • 0 in reply to Jianzhong Xu
    Prodigy 200 points

    Thank you, Jianzhong. I appreciate the update and your efforts in discussing this internally.

    We already have an external watchdog in our system. However, in this scenario it does not fire because the LDC hardware waits indefinitely for completion without blocking the CPU. The software thread remains alive and continues to service the external watchdog, so the system never resets even though the LDC request is permanently stalled.

    Therefore, we're looking for a way to recover the LDC/HTS from this "wait forever" state without requiring a full system reset.

    Please let me know if you need any additional logs or test results. Thank you.

    Ninh Nguyen
    BRs

  • 0 in reply to Ninh Nguyen
    TI__Guru 62430 points

    Hi Ninh,

    Ninh Nguyen said:
    We already have an external watchdog in our system. However, in this scenario it does not fire because the LDC hardware waits indefinitely for completion without blocking the CPU.

    Can you disable the LDC watchdog since you have an external (SoC level) watchdog?

    Based on our earlier communications, I believe LDC always completed the processing when the watchdog timer is disabled.

    To help us understand the situation better, can you dump the complete register HTS_HWA2_WDTIMER after the LDC watchdog timer times out?

    Can you also provide the following information?

    •  the LDC output block size
    •  the LDC mesh table

    Thank you.

    Regards,

    Jianzhong

  • 0 in reply to Jianzhong Xu
    TI__Guru 62430 points

    Hi Ninh,

    In addition, can you dump the following additional registers?

    Thank you.

    Jianzhong

  • 0 in reply to Jianzhong Xu
    Prodigy 200 points

    Hi  ,
    These are dump register

    --- raw devmem2 sample (unfiltered) ---
    /dev/mem opened.
    Memory mapped at address 0xffffa97b9000.
    Read at address  0x2C020008 (0xffffa97b9008): 0x00020217
    /dev/mem opened.
    Memory mapped at address 0xffffbc128000.
    Read at address  0x2C0105C8 (0xffffbc1285c8): 0x000CE500

    ### === register dump ===
    ==================== LDC0 CORE @ 0x2C020000 ====================
      NAME               OFFSET VALUE        NOTE
      REVISION           000h   0x64C60002
      PRIVATE_MEMSZ      004h   0x000A2A2A
      CTRL               008h   0x00020217   bit0 EN, bit1 LDMAPEN, bit2 BUSY
      CFG                00Ch   0x00000040
      MESHTABLE_CFG      010h   0x00000004
      MESH_FRSZ          014h   0x08800F10
      COMPUTE_FRSZ       018h   0x07800F00
      INITXY             01Ch   0x00800008
      INPUT_FRSZ         020h   0x08800F10   [15:0]W [31:16]H
      OUT_BLKSZ          024h   0x00014080   [7:0]OBW [15:8]OBH [19:16]PIXPAD
      AFF_AB             028h   0x00001000
      AFF_CD             02Ch   0x00000000
      AFF_EF             030h   0x00001000
      PWARP_GH           034h   0x00000000
      MESH_BASE_H        038h   0x00000000
      MESH_BASE_L        03Ch   0xA3578930
      MESH_OFST          040h   0x000003D0
      RD_BASE_H          044h   0x00000000
      RD_BASE_L          048h   0xB37E0000
      RD_OFST            054h   0x00000F10
      CH_RD_OFST         058h   0x00000000
      VBUSMR_CFG         05Ch   0x000000FA   tag count / burst length
      COREOUT_CHAN       060h   0x00000000
      DUALOUT_CFG        064h   0x01180118
      --- error / debug ---
      ERR_STATUS         200h   0x00000000   VBUSMR_ERR[10:8] SZOVF[5] MEMOVF[4:3] OUTB[2:0]
      DEBUG_CTRL         204h   0x00000000
      DEBUG_STATUS       208h   0x00000009
      FR_PDFTCH          20Ch   0x000D07A0   pixel bytes fetched
      FR_MDFTCH          210h   0x00003A20   mesh bytes fetched
      PIXMEMOVF_BLK      214h   0x00000000
      MESHMEMOVF_BLK     218h   0x00000000
      OUTOFBOUND_BLK     21Ch   0x00000000

    ==================== HTS @ 0x2C010000 ====================
      PID                040h   0x64CA0200
      --- HWA0_VISS ---
        SCHED_CTRL       +00h   0x00000001   bit0 SCH_EN, [3:1]PIPE, bit6 PAUSE, [10:7]STATE
        HOP              +04h   0x00000000
        WDTIMER          +08h   0x00000001   bit0 EN, bit1 STATUS, bit2 MODE(1=128K), [24:8]COUNT
        BW_LIMITER       +0Ch   0x00000000
        CONS0_CTRL       +20h   0x00000001
        PROD0_CTRL       +60h   0x00000000
        PROD0_COUNT      +68h   0x00000000
      --- HWA1_MSC ---
        SCHED_CTRL       +00h   0x00000000
        HOP              +04h   0x00000000
        WDTIMER          +08h   0x00000000
        BW_LIMITER       +0Ch   0x00000000
        CONS0_CTRL       +20h   0x00000000
        PROD0_CTRL       +60h   0x00000000
        PROD0_COUNT      +68h   0x00000000
      --- HWA2_LDC0 ---
        SCHED_CTRL       +00h   0x00000403
        HOP              +04h   0x00000000
        WDTIMER          +08h   0x000CE500
        BW_LIMITER       +0Ch   0x00000000
        CONS0_CTRL       +20h   0x00000000
        PROD0_CTRL       +60h   0x00000001
        PROD0_COUNT      +68h   0x00000000
      --- HWA3_LDC1 ---
        SCHED_CTRL       +00h   0x00000000
        HOP              +04h   0x00000000
        WDTIMER          +08h   0x00000000
        BW_LIMITER       +0Ch   0x00000000
        CONS0_CTRL       +20h   0x00000000
        PROD0_CTRL       +60h   0x00000000
        PROD0_COUNT      +68h   0x00000000

    ==================== PROGRESS CHECK (two samples, 2 s apart) ====================
      FR_PDFTCH        0x000D07A0
      FR_MDFTCH        0x00003A20
      DEBUG_STATUS     0x00000009
      CTRL             0x00020217
      LDC_PROD0_COUNT  0x00000000
      --- after 2 s ---
      FR_PDFTCH        0x000D07A0
      FR_MDFTCH        0x00003A20
      DEBUG_STATUS     0x00000009
      CTRL             0x00020217
      LDC_PROD0_COUNT  0x00000000

  • 0 in reply to Ninh Nguyen
    TI__Guru 62430 points

    Hi Ninh,

    Thank you for providing these register dumps. We'll be studying and get back to you asap.

    Can you share the LDC mesh table?

    Regards,

    Jianzhong

  • 0 in reply to Jianzhong Xu
    Prodigy 200 points

    Hi  ,
    Do you have more information about this issue ?

    Thanks,

  • 0 in reply to Ninh Nguyen
    TI__Guru 62430 points

    Hi Ninh,

    We're still investigating. Would you mind sharing your LDC mesh table?

    Thanks,

    Jianzhong

  • 0 in reply to Jianzhong Xu
    Prodigy 200 points

    Hi  ,
    Sr I cannot share this for you
    Thanks,

  • 0 in reply to Ninh Nguyen
    TI__Guru 62430 points

    Hi Ninh,

    Can you also enable bit TDONE_COUNT_EN in register  HTS_HWA2_HOP, and check the value of field TDONE_COUNT when the LDC WDT timer times out?

    From the register dumps you provided, the LDC output size is 128x64:

    Ninh Nguyen said:
    OUT_BLKSZ          024h   0x00014080   [7:0]OBW [15:8]OBH [19:16]PIXPAD

    Can you reduce this to 128x32 and see if the WDT timer times out?

    Thanks and regards,

    Jianzhong