This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

HDVPSS lockup.

Hi,

I'm experience an issue where one of the VIP ports lock up and I think it is related to advisory 2.0.2 in the latest errata but it is not detected as an overflow.

Looking at the VIP1 registers before the lockup:

0x48105a00: 0x00000001 0x0000a110 0x00000000 0x00000000
0x48105a10: 0x00000000 0x00000000 0x00000000 0x00000400

After lockup:

0x48105a00: 0x00000001 0x0000a110 0x00000000 0x00000000
0x48105a10: 0x00000000 0x00000000 0x00000010 0x00000c00

This usually occurs after a somewhat intense memory operation, similar to the 2.0.68 advisory.

Is it possible to get the field descriptions for these registers?

Best,

Andreas

  • Hi,

    I think you are capturing through VIP0 and you have dump registers for VIP1. Can you please do same exercise for base address 0x48105500.  Try dumping registers before starting capture, when capture is going on and when you think its locked up.

    Regards,

    Hardik Shah

  • Hi Hardik,

    I'm capturing from both VIP0 and VIP1 but VIP1 is the one locking up so the address is correct. I have noticed VIP0 lock up as well but not nearly as often.

    I have a rather complicated system where I use VIP0 to generate three H264 streams in various resolutions, bitrates etc etc. VIP1 is used as a PIP and runs through the scaler, mosaic and finally the display (thus my errata concern). I'll send a more detailed description of the pipelines tomorrow. I'm using OMX only, custom arago build but based on EZSDK 5.0.3.

    Tried the IOCTL recommendation but it doesn't seem to work well in my setup. Is it possible to get the register details for HDVPSS? Mark Pyne has my contact info.

    Oh, I also noticed that the second output port of the VIP1 (using VFCC) doesn't seem to work. VIP0 works fine and I use it to split the incoming stream into two half frame rate streams. Both VIP0 and VIP1 receive 1080p60.

    Keep me posted.

    Best,

    Andreas Engberg

  • Hi Hardik,

    here is the basic outline for my pipelines (slightly out of date). VFCC (VIP0) doesn't lock up but PIP (VIP1) does whenever JPEG conversion is activated. There is always a potential for software bugs on my side but they shouldn't really be able to lock up the VIP1.

    Best,

    Andreas

                       (0) - JPEG
                       /
            (0)-DEIH -+
           /           \
          /             (1) - HIGH
    VFCC-+              
          \             (0) - MEDIUM
           \           /
            (1)-DEIM -+
                       \
                        (1) - LOW
     
                     
            (0)-SC -(0)- MOSAIC -(0) VFDC - DC
           /           
          /             
    PIP-+              
          \             
           \           
            (1)
     
     

  • Hi,

    But from registers no lockup is seen. Is it possible that buffers are lost so capture driver is not getting any buffers to fill. So its dropping frames.

    Regards,

    Hardik Shah

  • Hi,

    maybe I'm asking the wrong question. Whenever I end up in this state, there are two registers that are different, 0x48105a18 and 0x48105a1c. Can I get details on those registers? Specifically 0x00000010 of 0x48105a18 and 0x00000c00 of 0x48105a1c.

    There are no incoming frames at this point.

    Thanks,

    Andreas

  • Hi Hardik,

    I dug through the smlogger dump and found this just before the VIP died:

    N:VPSS  P:2 #:24367 T:0000002b152cf6fb S:RESET Count:: 3 , curTime:: 369719

    VIP0 was locked up while VIP1 kept running. I forgot to dump the registers though.

    At this point, I think I have a workaround that is not too bad.

    One of the things that might be causing this is the video detection. I've noticed that removing a video source will cause a similar behavior. I'll explore this further.

    Best,

    Andreas