• State Resolved
  • Locked Locked
  • Replies 14 replies
  • Subscribers 99 subscribers
  • Views 1672 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Synchronization Problems with H3A Engine of DM355

Stefan Gachter
Intellectual 450 points

Dear all,

I have yet another problem, which bugs me now for weeks. I am trying to setup the AF engine of the H3A module, but have some strange behavior. In particular, the AF values are not stable for a given, fixed test pattern. This happens randomly after the restart of my system (shutdown -r now). Thus, I can startup and the AF engine provides stable values, then I can restart the system and the AF engine provides unstable values. This happens now and then.

In more detail:

My imager is configured to provide a constant image, with the values

R: 512
G: 512
B: 1023

(R and G are 512 to accomodate for offset in the FV calculator)

Thus, a blue image:

In the stable case, the AF engine accumulates the correct sum of pixels (No median filtering, no A-law comression):

 (The figure depices the "normalized" accumulated green pixel values for about 130 frames.)

In the unstable case, the AF engine accumulates incorrectly the sum of pixels:

The AF value jumps between 512 and 767.5. Note that 767.5 is the average of 1023 and 512. Thus, it seems, that AF engine confuses the image lines and reads from time to time twice the the same line or so. It looks like there is a synchronization problem, but I have no idea what it origins.

In order to tackle down the problem, I extended the AF driver to read the image values from the RAM instead instead from CCDC. The goal was to test the H3A engine independent from the CCDC (CCDC_CLK = 0 to disable the module) or imager. It turned out that a "synchronization" problem appears here as well.

The test pattern in the RAM looks as follows, which is the same as the test image:

512 1023
512 512

In the good case,  the AF engine accumulates the correct sum of pixels (No median filtering, no A-law comression):

 (The figure depices the "normalized" accumulated green pixel values for about 130 frames. Red and blue values are not shown here.)

In the bad case,  the AF engine accumulates the incorrect sum of pixels:

The values are constant over all frames as expected, but the sum is 506.88 instaed of 512. The bad case seems to occur under the same conditions as the unstable case above. It seems to be synchronization problem as well. The pixels values are not correctly read from the RAM.

I had a detailed look at AF driver and analyzed various cases, but came to the conclusion that the driver should be ok and that the problem is deeper on the "hardware" level.

Thus, my question are:

- How can the restart of the system influence the behavior of the H3A engine?
- Is it possible that the clock settings of H3A engine or CCDC module are "wrong"?
- How can I reset the H3A engine to defined a state?

I am really at loss. Any hint is welcomed.

- Has sombody else experience with the AF engine?

Regards,

Stefan

 

  • 0
    Intellectual 450 points

    In addition, I compared all the registers settings of VPFE between good/bad or stable/unstable case and there are no differences except for the dynamically allocated memory addresses. Therefore, I think that the configuration of the VPFE and in particular of the H3A engine should be ok. Furthermore, I am running only the AF module, AEW module is not loaded. So, if a H3A interrupt occurs it must come from the AF engine.

    According to the provided examples and documentation, I seem to do everything right...

    At least, does somebody actually use the AF engine of DM355 and can confirm that it runs properly his case?

    Thanks,

    Stefan

  • 0 in reply to Stefan Gachter
    TI__Expert 6850 points
    Stefan,
    To answer there questions it depends on what is causing the instability.  I think we need to find out what the clock settings are and what  the H3A settings are as a starting point, first.  Can you please share those?
  • 0 in reply to Jeff Hayes
    Intellectual 450 points

    Hi Jeff,

    Thanks for taking up the thread.

    I post here the log-files of the VPFE registers for the case where H3A engine is feed from CCDC. As mentioned, the register values are the same for stable and unstable case except for the address values.

    Stefan

    Stable case:
    1805.20100311-Test-88-RegisterValuesStable.zip

    Unstable case:
    3113.20100311-Test-89-RegisterValuesUnstable.zip

    H3A stable case:

    Reg: 0x01C70080 =   29819008 Val: 0x0008FE00 =     589312
    Reg: 0x01C70084 =   29819012 Val: 0xFFC057F9 = 4290795513
    Reg: 0x01C70088 =   29819016 Val: 0x00310004 =    3211268
    Reg: 0x01C7008C =   29819020 Val: 0x00000082 =        130
    Reg: 0x01C70090 =   29819024 Val: 0x00AA0064 =   11141220
    Reg: 0x01C70094 =   29819028 Val: 0x0000007A =        122
    Reg: 0x01C70098 =   29819032 Val: 0x80C8C000 = 2160640000
    Reg: 0x01C7009C =   29819036 Val: 0x00220040 =    2228288
    Reg: 0x01C700A0 =   29819040 Val: 0x00330004 =    3342340
    Reg: 0x01C700A4 =   29819044 Val: 0x0FCD0000 =  265093120
    Reg: 0x01C700A8 =   29819048 Val: 0x00000000 =          0
    Reg: 0x01C700AC =   29819052 Val: 0x00000040 =         64
    Reg: 0x01C700B0 =   29819056 Val: 0x00000000 =          0
    Reg: 0x01C700B4 =   29819060 Val: 0x00330040 =    3342400
    Reg: 0x01C700B8 =   29819064 Val: 0x0040000A =    4194314
    Reg: 0x01C700BC =   29819068 Val: 0x00400F80 =    4198272
    Reg: 0x01C700C0 =   29819072 Val: 0x001B0000 =    1769472
    Reg: 0x01C700C4 =   29819076 Val: 0x00800040 =    8388672
    Reg: 0x01C700C8 =   29819080 Val: 0x00000040 =         64
    Reg: 0x01C700CC =   29819084 Val: 0x00000000 =          0
    Reg: 0x01C700D0 =   29819088 Val: 0x00000000 =          0
    Reg: 0x01C700D4 =   29819092 Val: 0x00000000 =          0
    Reg: 0x01C700D8 =   29819096 Val: 0x00000000 =          0
    Reg: 0x01C700DC =   29819100 Val: 0x00000000 =          0
    Reg: 0x01C700E0 =   29819104 Val: 0x00000000 =          0
    Reg: 0x01C700E4 =   29819108 Val: 0x00000000 =          0
    Reg: 0x01C700E8 =   29819112 Val: 0x00000000 =          0

    VPSSCLK stable case:

    Reg: 0x01C70000 =   29818880 Val: 0x0001FF01 =     130817
    Reg: 0x01C70004 =   29818884 Val: 0x00000079 =        121

    H3A unstable case: 

    Reg: 0x01C70080 =   29819008 Val: 0x0008FE00 =     589312
    Reg: 0x01C70084 =   29819012 Val: 0xFFC0D7F9 = 4290828281
    Reg: 0x01C70088 =   29819016 Val: 0x00310004 =    3211268
    Reg: 0x01C7008C =   29819020 Val: 0x00000082 =        130
    Reg: 0x01C70090 =   29819024 Val: 0x00AA0064 =   11141220
    Reg: 0x01C70094 =   29819028 Val: 0x0000007A =        122
    Reg: 0x01C70098 =   29819032 Val: 0x86BE4000 = 2260615168
    Reg: 0x01C7009C =   29819036 Val: 0x00220040 =    2228288
    Reg: 0x01C700A0 =   29819040 Val: 0x00330004 =    3342340
    Reg: 0x01C700A4 =   29819044 Val: 0x0FCD0000 =  265093120
    Reg: 0x01C700A8 =   29819048 Val: 0x00000000 =          0
    Reg: 0x01C700AC =   29819052 Val: 0x00000040 =         64
    Reg: 0x01C700B0 =   29819056 Val: 0x00000000 =          0
    Reg: 0x01C700B4 =   29819060 Val: 0x00330040 =    3342400
    Reg: 0x01C700B8 =   29819064 Val: 0x0040000A =    4194314
    Reg: 0x01C700BC =   29819068 Val: 0x00400F80 =    4198272
    Reg: 0x01C700C0 =   29819072 Val: 0x001B0000 =    1769472
    Reg: 0x01C700C4 =   29819076 Val: 0x00800040 =    8388672
    Reg: 0x01C700C8 =   29819080 Val: 0x00000040 =         64
    Reg: 0x01C700CC =   29819084 Val: 0x00000000 =          0
    Reg: 0x01C700D0 =   29819088 Val: 0x00000000 =          0
    Reg: 0x01C700D4 =   29819092 Val: 0x00000000 =          0
    Reg: 0x01C700D8 =   29819096 Val: 0x00000000 =          0
    Reg: 0x01C700DC =   29819100 Val: 0x00000000 =          0
    Reg: 0x01C700E0 =   29819104 Val: 0x00000000 =          0
    Reg: 0x01C700E4 =   29819108 Val: 0x00000000 =          0
    Reg: 0x01C700E8 =   29819112 Val: 0x00000000 =          0

    VPSSCLK unstable case:

    Reg: 0x01C70000 =   29818880 Val: 0x0001FF01 =     130817
    Reg: 0x01C70004 =   29818884 Val: 0x00000079 =        121

  • 0 in reply to Stefan Gachter
    Intellectual 450 points

    Is somebody taking a closer look at the "synchronization" problem? Otherwise, I will contact my local sales representative to get further help on this issue.

    Stefan

  • 0 in reply to Stefan Gachter
    TI__Expert 6850 points

    Stefan,

     

    We are still looking into this.  Thanks for your patience.

  • 0 in reply to Jeff Hayes
    TI__Expert 6850 points

    Stefan,

    I'm afraid that the engineer best able to look into the deep technical details on this issue is out this week for Spring Break and will not return until next week.  Feel free to contact your local sales rep in the meantime.  Sorry for the delay.

     

  • 0 in reply to Jeff Hayes
    Intellectual 450 points

    Jeff,

    Thanks for your efforts.

    I will contact my local sales representative and, hopefully, get a step ahead until your expert is back.

    Regards,

    Stefan

  • 0 in reply to Stefan Gachter
    Intellectual 450 points

    Meanwhile I made the following discovery, which strongly supports the "synchronization problem" hypothesis...

    1) Switch my system on
    2) Run my AF test application, result is stable
    3) Quit my AF test application
    4) Switch PLL OFF, i.e. Bit 0 of 0x01C40900 = 0
    5) Switch PLL ON, i.e. Bit 0 of 0x01C40900 = 1
    6) Run my AF test application, result is unstable

     My colleague, who is developping the AEW part, has the same issue with the AEW engine.

    Thus,  simply switching the PLL on or off influences the behavior of H3A engine.

    Q: Is there a certain order of how to switch on PLL, Imager Clock, CCDC Clock, H3A Clock or whatever to guarantee a stable behavior?

    So far, I could not find much on startup order in the documentation. Did I miss something?

    Regards,

    Stefan

  • 0 in reply to Stefan Gachter
    TI__Mastermind 19985 points

    Stefan,

    Why would you want to switch off and on the PLL? ideally, there is a process for PLL control. Example is shown in UBL source code. I feel, it might not be your AF application that is unstable, it could be any code that might become unstable, if PLL is not controlled the right way.

    Can you add some delay after turning on PLL?This will ensure that the PLL is correctly locked and is giving out stable clock output.

     

    Regards,

    Anshuman

  • 0 in reply to Anshuman Saxena
    Intellectual 450 points

    Anshuman,

    Thanks for the comment. I will test the behavior with a delay.

    The goal of switching the PLL off is to set the system to standby mode. Maybe that's not the right way to do so...

    Up to now, I concentrated my efforts on the AF engine and had no closer look at the rest of the system setup. Indeed, there might be a missconfiugration of PLL and clock settings. Apart of the UBL source code, is there some additional documentation on how to best manage the boot up of clock and PLL?

    Regards,

    Stefan

  • 0 in reply to Stefan Gachter
    TI__Mastermind 19985 points

    Stefan,

    i have not checked the documentation, but i believe ARM subsystem guide should have such details about PLL programming. One other option is referring to GEL file.

     

    Regards,

    Anshuman

  • 0 in reply to Anshuman Saxena
    TI__Expert 6850 points

    Stefan,

    Please see Section 6.5 of the ARM SubSystem User's Guide for details on proper configuration of the PLL:

    http://focus.ti.com/lit/ug/sprufg5a/sprufg5a.pdf

     

     

  • 0 in reply to Jeff Hayes
    Intellectual 450 points

     

    ... problem solved.

    After taking a careful look at my clock and PLL settings and after re-reading the documentation, I discovered that the PCLK was equal to and not smaller than VPSSCLK/2. Thus, the instability disappeared by setting PCLK < VPSSCLK / 2.

    Actually, why does the PCLK have to be smaller than VPSSCLK/2? What is the technical motivation?

    Thanks again for your support... and being patient.

    Regards,

    Stefan

  • 0 in reply to Stefan Gachter
    TI__Expert 6850 points
    The pixel clock(PCLK) comes from an external device and it is asynchronous to DM365's clock.
    The PCLK domain will be synchronized with VPSSCLK/2 clock at the input stage.
    So, there is a restriction PCLK < VPSSCLK/2.