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.

AM335X Peripheral PLL freq. increases by +25%

Other Parts Discussed in Thread: TPS65910A, AM3359, AM3356

On some of our AM3354ZCZD72 boards the frequency of the peripheral PLL changes by +25% without any new values being written to the registers.

1. We detected the baudrates of all serial ports increasing by 25%, also the clock of the MMCx (µSD and SD cards) increased from 24MHz to 30MHz and USB not working.

2. Clocks for LCD, ASPx, CAN, PWM and even the 26MHz oscilator are correct and stable.

3. Reading the register values of the per PLL in good and bad condition showed no difference, same divider and lock bit set.  (No firmware write these registers after boot)

   CM_DIV_M2_DPLL_PER   (0x90a004ac) : 0x00000285

   CM_CLKMODE_DPLL_PERR (0x90a0048c) : 0x00000007

   CM_CLKSEL_DPLL_PER   (0x90a0049c) : 0x0403c019

   CM_IDLEST_DPLL_PER   (0x90a00470) : 0x00000001

4. If the regsiter CM_CLKSEL_DPLL_PER is again initialised the correct way (bypass, write, lock....) with the same value the baudrates / clocks become again correct in frequency.

   OUTREG32(PA_CM_CLKMODE_DPLL_PER, PLL_BYPASS_MODE);

   while(INREG32(PA_CM_IDLEST_DPLL_PER) != 0x00000100);

   clksel = clksel & (~0x7ffff);

   clksel = clksel | ((PERPLL_M << 0x8) | PERPLL_N);

   OUTREG32(PA_CM_CLKSEL_DPLL_PER, clksel);

   div_m2 = div_m2 & ~0x7f;

   div_m2 = div_m2 | PERPLL_M2;

   OUTREG32(PA_CM_DIV_M2_DPLL_PER, div_m2);

   clkmode = clkmode | 0x7;

   OUTREG32(PA_CM_CLKMODE_DPLL_PER, clkmode); 

   while(INREG32(PA_CM_IDLEST_DPLL_PER) != 0x1);

I can only concluded this would happen if the peripheral PLL is not running correctly internally in hardware ?

Who can give me some more info on the per-PLL internal working please (power pin, lock, ....) 

  • Hi Steve,
     
    This issue has been escalated to the factory team and they are discussing it offline with your TI support person. I suppose you are receiving feedback from him. So far it has been confirmed by the factory team that this behaviour hasn't been seen by any customer, both on AM335X and AM37X, as they have identical DPLL circuitry.
  • More info :

    We use the TPS65910A, VAUX1 supply for VDDA1P8V_USBx, voltage is within spec in normal operation (1.81V).

    On this line we have a 10µF, 10nF and 100nF capacitor.

     

    BUT this pin is also connected to the VPP pin (M5 on the ZCZ package), we found this also connector on the BeagleBone A3A.

    What's the function of this pin and when is it used ?  Can we disable it in Firmware maybe or is it no problem to connect it to 1.8V ?

     

    Kind Reagrds,

    Steve

     

     

     

  • VPP should be left unconnected in end designs.

  • Dear Biser,

     We will change this for our next production batch, but we already have 500 boards produced with this VPP pin connected to 1.8V

     What could be the faults or problems with this pin connected ?

     

     Kind Regards.

  • Steve, the behavior you are seeing is very strange.  Here are a few ideas to try to narrow down the problem

    -does the problem seem to occur after some event (maybe after a sleep/wake event, or something as simple as after 10min)? 

    -monitor VDDA1P8V_USB0 for stability, especially when the frequency of the peripherals change to unwanted values.  This voltage rail supplies the PER PLL.  Does this voltage rail supply other devices on your board, and are there possible noise sources on this rail?

    -for debug purposes, try setting CM_DIV_M2_DPLL_PER to 0x385.  This will force the CLKOUT of the DPLL always on.

    Regards,

    James

  • We don't use any power down or sleep modes, the application is running full time.

    The VDDA1P8V_USB comes from the PMIC (aux1) and is only connected to the VPP pin of the AM335x and to ADC1 via an 10k resistor.

    At normal opperation it's at 1.84V, I slowly lowered it to 1.25V (adding a resistor load) but the PLL still stayed stable. Only by a short to the ground for a second resulted in the PLL increasing to the higher freq. and stayed there after the voltage was again normal (again +25% more or less).

    I will run more tests at how low and how long the puls of glitch must be to result in the PLL running away and will set  M2 to 0x385 to compare.

    Please is there more info available on what strange / fault beheaver will result from connecting VPP to the 1.8V ?

     

     

  • Steve, you may be getting some droop on that rail from from those other sources.  Possibly the VPP may be inadvertently drawing a lot of current at certain times.  I will have to look into what you can do with the VPP.  If possible on one board, I would experiment with cutting the connection to VPP to see if that helps.  Then maybe cutting the connection to ADC (although i don't think that is the issue). 

    We usually use a ferrite bead to sensitive PLL rails to shield them from noise.  I know this is not an option for you.  I will try to come up with other alternatives.

    Regards,

    James

  • Steve, a couple of follow-ups:

    -I looked back at the Beaglebone schematics and it shows VPP connected to VDD_CORE (which is 1.1V), not a 1.8V rail.  So really you have that voltage out of spec, even though you are not really using it.  This can lead to unpredictable behavior, which you are seeing.  Ideally, as noted earlier in this thread, this should be left unconnected.  VPP is used to program internal efuses, which is not supported on your device.

    -another possibility to maybe reduce the effects of connecting this voltage is try setting bit 11 of 0x44e10100.  This register default value is 0x3281.  Set it to 0x3A81.  This is an undocumented register, but this should disable any potential efuse programming.

    Regards,

    James

  • Hallo James,

     It seems I can't set this bit at run-time, after writing 0x3A81 to this register the value read back is still 0x3281 as before ?

     Or is this bit not readable maybe ?

     Kind Regards,

     Steve

  • Hi Steve, the bit is in a Control Module register, so you have to be in an ARM privileged mode to write to it.  You should be able to write to it in u-boot at least.

    Regards,

    James

  • Steve, was there any conclusion on this.  Were you able to determine if the 1.8V on VPP was causing your abnormalities in the PLL output?

    regards,

    James

  • Hello James,

     It was not possible to change the regsiter value in our application, but only in the bootloader so a quick remote update in the field for testing is not possible.

     I succesfully tested the patch (in the bootloader) on one device, but this was only for a couple of hours.

     By now a small amound of devices have got the new bootloader and no fails have been reported yet.

     So I have good hope this will solve out problem.

     Kind Reagrds,

     Steve

  • Hi Steve,

    Were you finally able to verify that changing the value of register 0x44E10100 to 0x3A81 solved your AM335x Peripheral PLL frequency problem?

    My board is experiencing a very similar issue with the Peripheral PLL frequency. My board uses the AM3359, and we have VPP connected to VDD2_SMPS / VDD_CORE (1.1V), since the schematic of the ICE board had these nets connected.

    Here is the thread where I have been documenting my issue with the spontaneous changing of the AM335x Peripheral PLL frequency:

    http://e2e.ti.com/support/embedded/bios/f/355/t/274403.aspx

    Thanks,

    Jon

     

  • Hi Jon,

    Drilling a hole wasn’t possible, so we will have to wait until the next batch to cut the connection.

    Meanwhile we implemented 3 different software patches:

    - disable the effuse (set bit 11 of 0x44e10100) like TI proposed.

    - reinitiate the peripheral PLL when we detect the freq. haze changed (= if we lose serial communication, baud rate is wrong).

    - If all doesn’t' help we issue software reset to reboot.

    I haven't had any issue any more in the lab.

    regards,

    Steve

  • JJD said:

    We usually use a ferrite bead to sensitive PLL rails to shield them from noise.  I know this is not an option for you.  I will try to come up with other alternatives.

    Hi James,

    What sort of ferrite bead does TI normally use?

    We are experiencing issues with the Peripheral PLL of the AM335x on our board. The Peripheral PLL spontaneously changes frequency. We suspect that the board may occasionally experience a glitch on VDDA1P8V_USB0, which supplies the Peripheral PLL.

    Our design is based on the ICE schematic, which does not include any inductor or ferrite bead, but only a 0.01uF capacitor and 2.2uF capacitor on VDDA1P8V_USB0 / VAUX1 of TPS65910A. This supply rail is not connected to anything else... it goes straight to the AM335x.

    What ferrite bead or inductor does TI recommend for VDDA1P8V_USB0 of the AM335x?

    Thanks,

    Jon

  • Today I could reproduce this issue in the lab, I placed a GSM antenna above the processor (1 cm gap) and made a call (1800MHz network).

    Immediately the baud rate of the UART0 (debug) jumped to a lower frequency (22.8k instead of 115.2k), but all the rest kept on working (LCD, CPU …)

    I than started a program that just re-initializes and restart the Peripheral PLL to the normal freq. and the debug output came back to the normal 115.2k bd.

    Could it be that the processor or peripheral PLL is not immune to this frequency ?

    reagrds,

    Steve

     

  •  We have been looking at similar issues which may be related to the problem you have reported.

    In a few days we hope to publish a new Advisory in the silicon errata describing a possible solution.

    Regards,
    Paul

  • Hi Paul,

    Just curious to know if there is any new errata on this issue
    and if there is a need for the hardware change.

    Regards
    Prad.

  • We plan to add the following advisory to the next revision of the AM335x Silicon Errata.  This issue needs to be resolved at the system level and does not involve any silicon changes.

    Advisory 1.0.TBD         OSC0 and OSC1: Noise Immunity is improved when Crystal Circuit is connected directly to PCB Digital Ground

    Revision(s) Affected:    2.1, 2.0, 1.0

    Details:                         AM335x Data Sheet revisions F and earlier has specified OSC0 crystal circuit grounds only be connected to VSS_OSC in both ZCE and ZCZ packages, and OSC1 crystal circuit grounds only be connected to VSS_RTC in the ZCZ package.  The VSS_OSC and VSS_RTC terminals are connected to the VSS terminals inside AM335x which connects the crystal circuit to the PCB digital ground, but this ground connection is a higher impedance connection than a direct connection to the PCB digital ground.

    The higher impedance connection through AM335x to the PCB digital ground makes it easier for electrical noise to couple into the crystal circuit.  If the noise is large enough, it is possible the oscillator output may produce clock glitches to various internal logic circuits.  These clock glitches may cause unexpected behavior.

    Workaround:                 Connect the VSS_OSC and VSS_RTC terminals and respective crystal circuit component grounds directly to the nearest PCB digital ground, making it harder for noise to couple into the crystal circuit.

    Regards,
    Paul

  • Thank you so much for the confirmation.

  • I just got here in the course of investigating PLL instability issues we are seeing. We are seeing different PLLs break and change frequency (at least PER clock and DDR) by  25-30% too. We had changed our oscillator circuit design per TI recommendation to isolate the ground (or original design had them tied as stated above). We actually seem to see the PLL issue _more_ with the old design than with the isolated grounds.

    Clearly this issue needs some real attention at TI. 

  • We are seeing what appears to be the same problem.  At ramdom times, our Uart baud rate, SPI clock rate, and i2c rates will change by as much as +25%, and -80%.

    We've been reading through this forum thread, as well as the similar one about Task Execution Rate

    http://e2e.ti.com/support/embedded/tirtos/f/355/t/274403.aspx?pi199400=2

    We have tried 'writing to the undocumented register', but that has not worked.  We just had the same failure after a few hours of running with that change.

    Other notes : VPP is a no connect on our boards; we appear to have Rev 2 silicon; and we are running at 1Ghz.

    We are very close to releasing another revision of the PCB.  We were going to add the changes noted in the errata sheet regarding grounds for the two crystal oscillators.  From what was posted earlier, I'm not certain that will fix this problem.

    I agree with Iskander's comment about this issue needing further attention from TI.

    Also, regarding the similar thread, "Task Execution Rate ..." noted above, it was disheartening to see that "... this issue is getting resolved via direct communication, so we are marking this thread as Answered/Closed."

    It would have been useful to share that with the rest of the e2e community.

  • The early portion of this thread discusses a potential relationship to VPP being connected to 1.8 volts.  However, the VPP relationship was discussed before the issue was fully understood and has since been proven unrelated.

    It sounds like you are observing the issue described by Advisory 1.0.30.

    Have you tried to modify your current board design by simply adding a wire that connects the crystal component grounds to the nearest PCB ground to see if this eliminates the issue?  If not, you should try this before you complete your new PCB design.  If the modification does not provide enough noise immunity in your system, you may need to include other PCB changes to minimize noise coupling into the crystal circuit.

    Regards,
    Paul

  • We have gone through a couple of spins related to this issue (Advisory 1.0.30 directly contradicts previous recommendations, and neither tying the ground nor "floating" the ground worked for us. We ended up using an oscillator instead of a crystal, which cleaned the issue up.

    cheers

    /Tim

  • Hi Tim,

    we are facing similar problems on a custom board equipped with AM3356.

    Could you please specify if you adopted an active oscillator for OSC1 (32.768kHz) only, OSC0 only or both?

    Thanks a lot,

    Andrea

  • Andrea,

    We only used an oscillator for OSC0 (the 24MHz).

    cheers

    /Tim

  • Thank you for your help. This is the same thing Paul suggested here: http://e2e.ti.com/support/arm/sitara_arm/f/791/p/270632/1169154.aspx#1169154.

    Regards,

    Andrea