Post Go back to editing

PCG external trigger sync failure

Category: Hardware
Product Number: 0

Hi ADI team;

In our application, we have

  • 24.576MHz CLKIN as clock source for both PCG A and B
  • PCG A to generate 48K FSA and 12.288M CLKA
  • PCG B to generate 192K FSB and 12.288M CLKB
  • PCG B is triggered by PCG A  FSA
  • PCG A phase shift 1 and PCG B phase shift 67 so that PCG B FSB starts 64 CLKIN periods after FSA rising edge.

Most of the time it works. The blue one (FSB) is triggered by the red one(FSA)

However we have one device the stop working rarely, it happens after 50~300 tests. FSB starts earlier than FSA.

It seems to me the PCG B trigger event starts earlier than PCG A FSA. Hoverever I couldn't found any rising edge beforce FSA starts ouput.

May you advise to check/test for this failure?

Best Rgards

Totoro



Add input. and more tags
[edited by: totoro at 3:43 PM (GMT -4) on 28 Jul 2024]
Parents
  • Hi,

    Please provide your comments on the points below to assist you better on this issue.

    1.Please let us know the processor you are using.
    2.Whether you are using Ez-kit or custom board.
    3.How many boards have you tested and please confirm how many of them shows this issue?
    4.Let us know the silicon revision of both the boards?
    5.Are these boards exposed to any environmental tests?
    6.When were these DSPs purchased? You are facing only this issue or some other issue you are facing.
    7.Please confirm whether you have purchased from ADI authorized distributor?

    Regards,
    Nandini C

  • Hi Nandini;

    Thank you for your support.

    >> 1.Please let us know the processor you are using.

    ADSP 21562


    >> 2.Whether you are using Ez-kit or custom board.

    We use custom board based on EV-21562-AUTO design.


    >> 3.How many boards have you tested and please confirm how many of them shows this issue?

    We have made thounds of boards and only 5 of them showed this issue.
    One of these boards shows more often while the other four boards showed once only.
    We test other 7 boards for ~56000 times*DUT but never get this issue reproduced.

    >> 4.Let us know the silicon revision of both the boards?

    All of them are Rev0.2.

    >> 5.Are these boards exposed to any environmental tests?

    No.

    >> 6.When were these DSPs purchased? You are facing only this issue or some other issue you are facing.

    Well I don't know the detail but we had made the bussies thru ADI sales manager.
    Other issues had been resolved so this is the only one for now.

    >> 7.Please confirm whether you have purchased from ADI authorized distributor?

    Yes.

    Best Regards
    Totoro

  • Hi,

    Can you please confirm whether in all the thousand boards you have left these pins (PA14/15, PB0/1/5, JTAG) as floating, or in these particular 5 boards you have made the changes.

    If any specific description and notes are not suggested in data Sheet for Designer Reference, the unused pins can be left floating. For the best practice a 10K external pull-down resistance can be used to connect the pin to GND.

    As mentioned in the note (Page No: 43/102) under "Table 18. ADSP-2156x Designer Quick Reference" in the ADSP-2156x datasheet, "the internal pull-up/pull-down design holds the internal path from the pins at the expected logic levels. To pull up or pull down the external pads to the expected logic levels, use external resistors".

    The link for the datasheet is given below.

    www.analog.com/.../adsp-21562-21563-21565-21566-21567-21569.pdf

    Regards,
    Nandini C

  • Hi Nandini,

    These pins are floating among all boards.

    Most pins are used and connects to other ICs except PA14/15, PB0/1/5, JTAG. The schematic had been reviewed by ADI team.

    Best Regards,

    Totoro

  • Hi Totoro,

    Will it be possible for you to share the code for reviewing it.

    Also, in meanwhile during failure time, did you try to restart the PCG, and does it work?

    Regards,
    Nandini C

  • Hi Nandini;

    We can't share the whole project but here are some code about PCG and SRU.

    void PCG_Init(void)
    {
        /**** PCG0_A ****/
        ADI_PCG_CLK_INFO gClkInfoA = { ADI_PCG_CLK_CLKIN0, 2u, false }; /* 12.288MHz */
        ADI_PCG_FS_INFO gFsInfoA = { ADI_PCG_FS_CLKIN0, 512u, 256u, 1u, false, ADI_PCG_FSBYPASS_MODE_NORMAL }; /* 48KHz */
        adi_pcg_Init(ADI_PCG_DEV_A, &gClkInfoA, &gFsInfoA);
    
        /**** PCG0_B ****/
        ADI_PCG_CLK_INFO gClkInfoB = { ADI_PCG_CLK_CLKIN0, 2u, true }; /* 12.288MHz */
        ADI_PCG_FS_INFO gFsInfoB = { ADI_PCG_FS_CLKIN0, 128u, 64u, 67u, true, ADI_PCG_FSBYPASS_MODE_INV }; /* 192KHz */
        adi_pcg_Init(ADI_PCG_DEV_B, &gClkInfoB, &gFsInfoB);
    
        /**** PCG0_C ****/
        ADI_PCG_CLK_INFO gClkInfoC = { ADI_PCG_CLK_CLKIN0, 16u, false }; /* 1.536MHz */
        ADI_PCG_FS_INFO gFsInfoC = { ADI_PCG_FS_CLKIN0, 512u, 256u, 8u, false, ADI_PCG_FSBYPASS_MODE_NORMAL }; /* 48KHz */
        adi_pcg_Init(ADI_PCG_DEV_C, &gClkInfoC, &gFsInfoC);
    }

    void SRU_Init(void)
    {
        /* PADS0 DAI0 Port Input Enable Control Register */
        *pREG_PADS0_DAI0_IE = BITM_PADS_DAI0_IE_VALUE;
    
        /* PADS0 DAI1 Port Input Enable Control Register */
        *pREG_PADS0_DAI1_IE = BITM_PADS_DAI1_IE_VALUE;
    
        SRU(PCG0_CLKA_O, DAI0_PB20_I);
        SRU(HIGH, DAI0_PBEN20_I);
    
        SRU(PCG0_FSB_O, DAI0_PB04_I);
        SRU(HIGH, DAI0_PBEN04_I);
        SRU(PCG0_FSA_O, DAI0_PB08_I);
        SRU(HIGH, DAI0_PBEN08_I);
        SRU(DAI0_PB08_O, PCG0_SYNC_CLKB_I); //48KHz and 192KHz sync
    
        SRU2(PCG0_CLKC_O, DAI1_PB06_I);
        SRU2(HIGH, DAI1_PBEN06_I);
    
        SRU(PCG0_CLKA_O, SPT0_ACLK_I); //Sport 0A
        SRU(PCG0_FSA_O, SPT0_AFS_I);
        SRU(DAI0_PB01_O, SPT0_AD0_I);
        SRU(LOW, DAI0_PBEN01_I);
    
        SRU(PCG0_CLKA_O, SPT0_BCLK_I); //Sport 0B
        SRU(PCG0_FSA_O, SPT0_BFS_I);
        SRU(DAI0_PB02_O, SPT0_BD0_I);
        SRU(LOW, DAI0_PBEN02_I);
    
        SRU(PCG0_CLKA_O, SPT1_ACLK_I); //Sport 1A
        SRU(PCG0_FSA_O, SPT1_AFS_I);
        SRU(DAI0_PB05_O, SPT1_AD0_I);
        SRU(LOW, DAI0_PBEN05_I);
    
        SRU(PCG0_CLKA_O, SPT3_ACLK_I); //Sport 3A
        SRU(PCG0_FSA_O, SPT3_AFS_I);
        SRU(SPT3_AD0_O, DAI0_PB06_I);
        SRU(HIGH, DAI0_PBEN06_I);
    
        SRU(PCG0_CLKA_O, SPT3_BCLK_I); //Sport 3B
        SRU(PCG0_FSA_O, SPT3_BFS_I);
        SRU(SPT3_BD0_O, DAI0_PB07_I);
        SRU(HIGH, DAI0_PBEN07_I);
    
        SRU(PCG0_CLKA_O, DAI0_PB19_I);
        SRU(HIGH, DAI0_PBEN19_I);
        SRU(HIGH, INV_DAI0_PB19_I);
        SRU(PCG0_FSA_O, DAI0_PB03_I);
        SRU(HIGH, DAI0_PBEN03_I);
    
        SRU(PCG0_CLKA_O, SPT2_ACLK_I); //Sport 2A
        SRU(PCG0_FSA_O, SPT2_AFS_I);
        SRU(DAI0_PB10_O, SPT2_AD0_I);
        SRU(LOW, DAI0_PBEN10_I);
    
        SRU(PCG0_CLKA_O, SPT1_BCLK_I); //Sport 1B
        SRU(PCG0_FSA_O, SPT1_BFS_I);
        SRU(DAI0_PB09_O, SPT1_BD0_I);
        SRU(LOW, DAI0_PBEN09_I);
    
        SRU2(PCG0_CLKC_O, DAI1_PB20_I);
        SRU2(HIGH, DAI1_PBEN20_I);
        SRU2(PCG0_FSC_O, DAI1_PB19_I);
        SRU2(HIGH, DAI1_PBEN19_I);
    
        SRU2(PCG0_CLKC_O, SPT4_ACLK_I); //Sport 4A
        SRU2(PCG0_FSC_O, SPT4_AFS_I);
        SRU2(DAI1_PB10_O, SPT4_AD0_I);
        SRU2(LOW, DAI1_PBEN10_I);
    
        SRU2(PCG0_CLKC_O, SPT4_BCLK_I); //Sport 4B
        SRU2(PCG0_FSC_O, SPT4_BFS_I);
    
        //SRC config
        SRU2(PCG0_CLKC_O, SRC4_CLK_OP_I); //SRC CLK
        SRU2(DAI1_PB08_O, SRC4_CLK_IP_I);
        SRU2(LOW, DAI1_PBEN08_I);
        SRU2(PCG0_FSC_O, SRC4_FS_OP_I); //SRC FS
        SRU2(DAI1_PB09_O, SRC4_FS_IP_I);
        SRU2(LOW, DAI1_PBEN09_I);
        SRU2(DAI1_PB07_O, SRC4_DAT_IP_I); //SRC DATA
        SRU2(LOW, DAI1_PBEN07_I);
        SRU2(SRC4_DAT_OP_O, SPT4_BD0_I);
    
        SRU2(PCG0_CRS_CLKA_O, DAI1_PB04_I); //PCG cross, from PCG0_CLKA to DAI1
        SRU2(HIGH, DAI1_PBEN04_I);
        SRU2(PCG0_CRS_FSA_O, DAI1_PB03_I); //PCG cross, from PCG0_FSA to DAI1
        SRU2(HIGH, DAI1_PBEN03_I);
    
        SRU2(DAI1_PB04_O, SPT5_ACLK_I); //Sport 5A
        SRU2(DAI1_PB03_O, SPT5_AFS_I);
        SRU2(SPT5_AD0_O, DAI1_PB01_I);
        SRU2(HIGH, DAI1_PBEN01_I);
    
        SRU2(HIGH, DAI1_PB02_I);
        SRU2(HIGH, DAI1_PBEN02_I);
        SRU2(HIGH, DAI1_PB05_I);
        SRU2(HIGH, DAI1_PBEN05_I);
    }

    int main(){
        ......
        PCG_Init();
        SRU_Init();
        .....
        while(1) {
             .....
        }
    }

    We changed PB08 SRU setting and place it before PCG init, the issue does not show up for ~5000 tests.

    We had looked at ADI sample code, the init sequence is SRU -> PCG B -> PCG A.

    For our application it is PCG A -> PCG B -> SRU.

    >> Also, in meanwhile during failure time, did you try to restart the PCG, and does it work?

    We had try reset ADSP and it work again. To restart PCG while keep adsp running, we need to do more extra work, probably code a custom CMD4 to restart PCG manually.  I will give it a try.

    Best Regards

    Totoro

  • Hi,

    We tried to replicate your issue, but the issue is not replicated. We could be able to get proper Frame sync as FSA triggering first and then FSB triggering second.

    We changed PB08 SRU setting and place it before PCG init, the issue does not show up for ~5000 tests. We had looked at ADI sample code, the init sequence is SRU -> PCG B -> PCG A. For our application it is PCG A -> PCG B -> SRU.

    >> As you have mentioned previously, "We have made thounds of boards and only 5 of them showed this issue. One of these boards shows more often while the other four boards showed once only."

    Whether you have done this configuration (PCG A -> PCG B -> SRU) for all thousand boards, in that you have faced issue only in 5 boards.

    Did the issue not occur at all in these 5 boards after placing the PB08 SRU settings before PCG init. Also, could you please follow the configuration as SRU -> PCG and let us know the frequency of issue occurring.
     
    Regards,
    Nandini C

  • Hi,

    >> We tried to replicate your issue, but the issue is not replicated. We could be able to get proper Frame sync as FSA triggering first

    >> and then FSB triggering second.

    Yes, we fail to replicate on other "good" boards too.

    >>>>We changed PB08 SRU setting and place it before PCG init, the issue does not show up for ~5000 tests. We had looked at ADI

    >>>>sample code, the init sequence is SRU -> PCG B -> PCG A. For our application it is PCG A -> PCG B -> SRU.

    >> As you have mentioned previously, "We have made thounds of boards and only 5 of them showed this issue. One of these boards shows more often while the other four boards showed once only."

    >>Whether you have done this configuration (PCG A -> PCG B -> SRU) for all thousand boards, in that you have faced issue only in 5 boards.

    Yes. 4 of these 5 probrlematic boards were reported by our customer. I had requested one to test but failed replicate the issue.


    >>Did the issue not occur at all in these 5 boards after placing the PB08 SRU settings before PCG init. Also, could you please follow >>the configuration as SRU -> PCG and let us know the frequency of issue occurring.

    I only have 2 boards now, and had been running test for 1 week. The issue has not been reproduced yet.
     
    Best Regards,
    Totoro

  • Hi Nandini,

    We just move PCG FSA, FSB and trigger DAI(PB08) SRU setting before PCG:

      int main(){
        // Init FSA FSB and PB08 SRU first
        SRU(PCG0_FSB_O, DAI0_PB04_I);
        SRU(HIGH, DAI0_PBEN04_I);
        SRU(PCG0_FSA_O, DAI0_PB08_I);
        SRU(HIGH, DAI0_PBEN08_I);
        SRU(DAI0_PB08_O, PCG0_SYNC_CLKB_I); //48KHz and 192KHz sync
    
        PCG_Init();
       // init other sru 
        SRU_Init();
        .....
        while(1) {
        .....
        }
    }

    One DUT had passed 9700 tests. Before this change, it fails every hundreds tests.

    Best Regards

    Totoro

  • Hi,

    Can you please confirm the default state of input given to the PCG0_SYNC_CLKB_I signal before configuring the SRU?
    If it is in floating state, it could be triggering the high state before configuring the SRU DAI configuration.

    If you are configuring the SRU after PCG configuration, it will first start initiating the PCG signal. It may be the cause of triggering the PCG B first.

    Please try to follow the configuration as SRU -> PCG to route the signal respectively.

    It is also good practice to tie all unused inputs to a high or low level to reduce dynamic power consumption.

    It's suggestive to follow the same for all the boards to prevent any possibilities of issues in the future.

    Regards,
    Nandini C

  • Hi Nandini,

    >>Can you please confirm the default state of input given to the PCG0_SYNC_CLKB_I signal before configuring the SRU?
    >>If it is in floating state, it could be triggering the high state before configuring the SRU DAI configuration.

    The default state of PCG0_SYNC_CLKB_I is selected by DAI_CLK4.IN5, it is b'11110. Based on TRM, this selection code is "Logic level low".

    We don't touch PCG0_SYNC_CLKB_I before SRU init.

    >> If you are configuring the SRU after PCG configuration, it will first start initiating the PCG signal. It may be the cause of triggering the PCG B first.

    >> Please try to follow the configuration as SRU -> PCG to route the signal respectively.

      int main(){
        SRU(HIGH, DAI0_PBEN08_I)
    
        PCG_Init();
       // init other sru 
        SRU_Init();
        .....
        while(1) {
        .....
        }
    }

    We had did another experiment as above: enable PB08 pin buffer before PCG and let other SRU untouch.

    This way I want monitor PB08_O signal earlier when internal SRU routing change. However I don't see any rising edge before PCG B starts.

    >>It is also good practice to tie all unused inputs to a high or low level to reduce dynamic power consumption.

    >> It's suggestive to follow the same for all the boards to prevent any possibilities of issues in the future.

    We have updated the firmware to init SRU first then PCG. But we need to chase down the root cause and report to our custom in confidence that we solve the real issue.

    Best Regards,
    Totoro

  • Hi,

    The DAI pins interface with the processor’s signal routing unit (SRU), an adaptable system designed to manage intricate signal pathways within the processor. The SRU facilitates the routing of DAI pins to various internal peripherals as required. So, it is recommended to route the pins and then initialize them to ensure proper initialization across the peripherals.

    Since the issue no longer occurs after configuring the SRU and PCG accordingly, it’s advisable to follow this approach to prevent similar issues in the future for all the boards as well.
    Regards,
    Nandini C
Reply
  • Hi,

    The DAI pins interface with the processor’s signal routing unit (SRU), an adaptable system designed to manage intricate signal pathways within the processor. The SRU facilitates the routing of DAI pins to various internal peripherals as required. So, it is recommended to route the pins and then initialize them to ensure proper initialization across the peripherals.

    Since the issue no longer occurs after configuring the SRU and PCG accordingly, it’s advisable to follow this approach to prevent similar issues in the future for all the boards as well.
    Regards,
    Nandini C
Children
No Data