AM3352: PLL output frequency increased during running time

Part Number: AM3352


Tool/software:

On customer's board/system, there is rare case the UART baud rate increased from 115200bps to ~150Kbps, other peripherals like CAN, Ethernet still work, but USB, timer which share the same 48MHz clock are impacted. it need reset AM335x to recover.

The system use 25MHz crystal as clock. after the issue happen, the input clock is still stable at 25MHz.

Customer asks if there is noise on the clock, or the clock is not stable during run time, will it result in PLL output clock frequency change and stay on the changed frequency can't recover?

Does  the PLL lock multiples or lock the output frequency?

Is there way to detect the PLL output abnormality? then software can involve to reset the device.

  • Tony, from what you describe, it seems the CLKOUT from the Peripheral PLL is getting corrupted with a different frequency output.  USB, as shown is a different output.  

    Is it possible for the customer to monitor this frequency using CLKOUT2? See below

    If there is noise in the system, that typically would affect the input system clock, and thus affect all the PLLs.  This problem seems to be localized to one output of one PLL

    Can they check the PER PLL registers after a failure, to see if anything has changed from a working condition?  They are kinda spread out in the memory map, so if they can dump 0x44E0_046C-0x44E0_04AC, that would capture all of them.

    Regards,

    James

  • 1.  0x44E0_046C-0x44E0_04AC  region is read and compared with that of normal status, no changes.

    2.  clkout2 pin is not routed out, can't probe. only clkout1 is routed out.

    3.  Can software check the PER_CLKOUT_M2 PLL lock loss status?

  • There is no lock loss status bit to be checked.  

    -When the frequency increases, can you try to unlock and relock the PER PLL?  Does the frequency go back to normal?

    -when the frequency increases, is there anything unusual that is executing in the system?  Does is happen during a high activity period, especially on a parallel bus like GPMC or display?

    -do you have any large parallel busses on the board?  If so, you may want to run an experiment which switches this bus as fast as possible (eg, on display, send all zeros and all ones repeatedly).  This will increase switching noise on the board.  If you see an increase in the frequency of failures, this will give you a clue that the issue could be noise related.

    -Ensure you have the proper decoupling on the PLL supplies.  The PER PLL is supplied by VDDA1P8V_USB0.  See Table 5-14 in the datasheet.

    Regards,

    James