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.

Problem initializing 5505A PLL at Power On Reset but not at hardware reset

We have a system based on the 5505A DSP.  We are using a 32 Khz clock crystal into the RTC of the DSP.  Our code initializes the theSYSCLK to 100 Mhz.  At power on the DSP boots and the resulting SYSCLK is 12 mhz.  Pulling the reset pin low at this point, the DSP reboots and SYSCLK is now 100 Mhz.

At power on reset sequence, reading back the registers immediately after the initialization is complete shows that the PLL registers failed to update with the new values.  The values assigned during ROM Boot are the values that are read.  After a hardware reset (after a power on reset sequence), the PLL registers have the new programmed values.

I also noticed that TESTLOCKMON bit is asserted  by the time it is read for the first time. 

Here is the initialization code:

void USB_initPLL(void)
{
     Uint16    timeout;

     timeout
= CSL_USB_PLL_TIMEOUT;

    
/* bypass PLL */
    CSL_FINST(sysCtrlRegs
->CCR2, SYS_CCR2_SYSCLKSEL, BYPASS);

    
/* Configure the PLL for 100 MHz */
     sysCtrlRegs
->CGICR = 0x8000;
     sysCtrlRegs
->CGOCR = 0x0000;
     sysCtrlRegs
->CGCR2 = 0x0806;
     sysCtrlRegs
->CGCR1 = 0x8BE8;

   
/* Busy wait until TESTLOCKMON is high or timeout */
   
while(!((sysCtrlRegs->CGCR2) & (0x08)))
   
{
           timeout
--;
          
if(timeout == 0)
          
{
               
break;
          
}
   
}

   
/* Switch to PLL clk */
    CSL_FINST(sysCtrlRegs
->CCR2, SYS_CCR2_SYSCLKSEL, LOCK);
}

  • Another peice of information.

    In the process of debugging the code, I removed the function call and added the body of the function in place of calling the function.  The PLL then properly initialized!

    What is the root cause?

  • Your code looks OK. Please make sure the the function is executed in your program. According to your last update, it seems that the function was not properly executed.

  • I am able to step throught the code with the debugger for both cases.  The pll fails to initialize only when the system is powered up.  If I do a hardware reset after power up, the pll is initialized correctly.

  • Greg,

    It appears that reset signal is not properly applied to the DSP while powering up. Did you probe the reset signal? It should be held low until all power domains reach their operating voltage level. 

  • The reset signal is  held low for 200 ms after power on.  The bootcode in the DSP succesfully initializes the PLL to 12 Mhz.  It takes approximately 300 ms for the bootloader to load our software from flash.  At the start of our code we are trying to program the PLL to 100 Mhz but it stays at 12 Mhz. 

    I have written some test software that reads back the PLL configuration registers immediately after the PLL init takes place.  The values read back are the ones programed by the DSP bootcode.  After a reset the values readback are the ones our software wrote and the PLL is now at 100 mhz.

     

  • Greg,

    One thing I missed was that you need to wait at least 4msec before enabling PLL (from bypass to lock). However, you said that the PLL registers were not properly configured after executing your pll configuration function? It does not make sense to me. Are you sure that your code was successfully loaded by bootloader and the function got executed? 

     

    Regards,

    Peter Chung

  • The code is successfully loaded and executed after boot.

    The CSL code to initialize the PLL monitors the TESTCLKMON to tell when the PLL is locked.  It does not wait 4 ms per the application note.

    I am using the GPIO to track when the code is executing.  I have also set up the PLL clk to be output on the EXTCLK pin.  When I use the inline code I can see the PLL immediately start to change frequency.  When I use a funtion call to execute the exact same code, I do not see the PLL changing frequency.

  • Greg,

     

    I think we should have a call to discuss the issue in depth. I just got an email from Tim about this issue. I suggest him a call with you. 

    I am fully booked this week and I am going to visit Europe next week, so I become available the following week. Is it OK with you?

     

    Regards,

    Peter Chung

     

  • You picked a good week to be in Europe.  I hope the weather doesn't interfere with your travel plans.  Have Tim set up the meeting when you get back.

  • Greq,

    Tim set up a call tomorrow morning. Before the call, could you please increas stack size and see it it fixes the issue? Talk to you soon.

     

    Regards,

    Peter Chung

     

  • I set the stack size to 8K.  Same beahavoir as before.

  • I solved the problem.  The basic issue is that in the CSL uses a global variable to point to the system control registers (sysCntrlRegs).  This pointer is not initialized until the csl init usb routine is called.  Since we are configuring the PLL at system start before the USB is initialized, the pointer is not initialized and the PLL does not get configured. When the USB is intialized, the sysCntlRegs pointer is set to the correct value.  If a hardware reset occurs after this, the contents of the memory are intact, thus sysCntlRegs will actually point to the system registers after a hardware reset and the PLL gets configured correctly.

    The reason that the inline code worked is because since I didn't have access to the USB's sysCntrlRegs pointer, I created and initialized a pointer to the system control registers.

    You might want to update the CSL usb pll init routine to initialize the sysCntlRegs pointer.

  • Greg,

    Thank you so much for your update and I am glad that the problem has been solved.

    Sure, I will inform this to our S/W team.

    Best Regards,

    Peter Chung