Cannot remove PLL from bypass mode?

Hi Jonathan,

Have you tried the  same GEL file before with other working boards? Are you testing the custom AM1705 board for the first time? If that is the situation please make sure the OSCIN input clock, power and reset are coming out properly.

Regards

Antony

Hello, Antony,

Thanks for your quick response!

Yes, the same GEL PLL code works correctly with the Spectrum Digital EVMAM1707 evaluation board.  The GEL files are not *identical*, due to pinmux and data bus differences, but they both hook into shared PLL code (see attached).

I'll see what our hardware engineer has to say about the signals you mentioned, but I can confirm that with PLL kept in bypass mode (crystal frequency 24 MHz), our board can run simple test applications for the following modules:

• GPIO
• UART (with interrupts)
• EMIFB (miraculous? uses 456 MHz values)

Jonathan,

Can you try this Setup_PLL( ) function attached. Just copy and paste it in your GEL script  that is set for your frequency.

Regards

Antony

Setup_PLL()
{
    int i = 0;

    /* Configure ARM, DSP at 456MHz, EMIFs at 114MHz */
    unsigned int DIV45_EN = 1;
    unsigned int CLKMODE = 0;
    unsigned int PLLM = 18;
    unsigned int POSTDIV = 0;
    unsigned int PLLDIV3 = 3;
    unsigned int PLLDIV5 = 3;
    unsigned int PLLDIV7 = 5;

	// Moved step 2c and 2d to step 0
   /*Set PLLEN=0 and PLLRST=0, Reset the PLL*/
    PLL0_PLLCTL &=  0xFFFFFFFE; 	/*PLL BYPASS MODE*/
   
   /*wait for 4 cycles to allow PLLEN mux switches properly to bypass clock*/
   for(i=0; i<PLLEN_MUX_SWITCH; i++) {;}   /*Make PLLEN_MUX_SWITCH as bootpacket*/

   /*Select the Clock Mode bit 8 as External Clock or On Chip Oscilator*/
	PLL0_PLLCTL &= 0xFFFFFEFF;  
    PLL0_PLLCTL |= (CLKMODE<<8);  /* Make CLKSRC as BootPacket to pass the value*/

   /*Set PLLENSRC '0',bit 5, PLL Enable(PLLEN) selection is controlled through MMR*/
    PLL0_PLLCTL &=  0xFFFFFFDF; 
   
   /*PLLCTL.EXTCLKSRC bit 9 should be left at 0 for Primus*/
    PLL0_PLLCTL &=  0xFFFFFDFF;

   /* Clear PLLRST bit to 0 -Reset the PLL */
   PLL0_PLLCTL &= 0xFFFFFFF7; 	
  
   /*Disable the PLL output*/ 
   PLL0_PLLCTL |= 0x10; 		
   
   /*PLL initialization sequence*/
   
   /*Power up the PLL- PWRDN bit set to 0 to bring the PLL out of power down bit*/
   PLL0_PLLCTL &= 0xFFFFFFFD;
   
   /*Enable the PLL from Disable Mode PLLDIS bit to 0 - This is step is not required for Primus*/
   PLL0_PLLCTL &= 0xFFFFFFEF;
   
   /*PLL stabilisation time- take out this step , not required here when PLL in bypassmode*/
  /* for(i=0; i<PLL_STABILIZATION_TIME; i++) {;}  /* Make PLL_STABILIZATION_TIME as bootpacket*/
   
   /*Program the required multiplier value in PLLM*/
   PLL0_PLLM    = PLLM; /* Make PLLMULTIPLEIR as bootpacket*/

   /*If desired to scale all the SYSCLK frequencies of a given PLLC, program the POSTDIV ratio*/
   PLL0_POSTDIV = 0x8000 | POSTDIV; /* Make POSTDIV as bootpacket*/

   /*If Necessary program the PLLDIVx*/
   /*Check for the GOSTAT bit in PLLSTAT to clear to 0 to indicate that no GO operation is currently in progress*/
   while(PLL0_PLLSTAT & 0x1==1){}

   /*Program the RATIO field in PLLDIVx with the desired divide factors. In addition, make sure in this step you leave the PLLDIVx.DxEN bits set so clocks are still enabled (default).*/
    PLL0_PLLDIV3 = 0x8000 | PLLDIV3; /* Make PLLDIV3 as bootpacket, do it for other PLLDIVx to if required*/
    PLL0_PLLDIV5 = 0x8000 | PLLDIV5; /* Make PLLDIV5 as bootpacket, do it for other PLLDIVx to if required*/
    PLL0_PLLDIV7 = 0x8000 | PLLDIV7; /* Make PLLDIV7 as bootpacket, do it for other PLLDIVx to if required*/

    /*Set the GOSET bit in PLLCMD to 1 to initiate a new divider transition.*/
    PLL0_PLLCMD |= 0x1;

	/*Wait for the GOSTAT bit in PLLSTAT to clear to 0 (completion of phase alignment).*/
    while(PLL0_PLLSTAT & 0x1==1) { } 
   
 
   /*Wait for PLL to reset properly. See PLL spec for PLL reset time - This step is not required here -step11*/
  /* for(i=0; i<PLL_RESET_TIME_CNT; i++) {;}   /*128 MXI Cycles*/ /*Make PLL_RESET_TIME_CNT as boot packet*/
      
   /*Set the PLLRST bit in PLLCTL to 1 to bring the PLL out of reset*/
   PLL0_PLLCTL |= 0x8;
   
   /*Wait for PLL to lock. See PLL spec for PLL lock time*/
   for(i=0; i<PLL_LOCK_TIME_CNT; i++) {;} /*Make PLL_LOCK_TIME_CNT as boot Packet*/ 
   
   /*Set the PLLEN bit in PLLCTL to 1 to remove the PLL from bypass mode*/
   PLL0_PLLCTL |=  0x1;

   KICK0R = 0x83e70b13;  // Kick0 register + data (unlock)
   KICK1R = 0x95a4f1e0;  // Kick1 register + data (unlock)
   CFGCHIP3 |= 0x4;       // Enable 4.5 divider PLL
   CFGCHIP3 |= 0x1;       // Select 4.5 divider for EMIFB clock source only (not EMIFA)

   GEL_TextOut( "PLL Setup Complete\n" );
}

Hi Antony,

Thanks for the GEL function, but unfortunately, we still get the same error message:

ARM9_0: Trouble Writing Memory Block at 0x1c11100 on Page 0 of Length 0x4
ARM9_0: GEL: Error while executing OnTargetConnect(): target access failed.
ARM9_0: Error: Failed to get PRSC status

Tracing with GEL_TextOut() shows the same problem - hanging after the line

PLL0_PLLCTL |=  0x1;

For what it's worth, the same behavior occurs if I just comment out that line in the GEL file, and then set the bit manually with the xds100v2 debugger ("Registers > PLL0ARM > PLLCTL > PLLEN").  In this case, the error message is slightly different:

ARM9_0: Trouble Writing Memory Block at 0x1c11100 on Page 0 of Length 0x4
ICEPICK_C: Error: (Error -150 @ 0x0) This utility failed to operate the adapter for a custom emulator. The adapter returned an error for unknown reasons. (Emulation package 5.0.520.0)
ARM9_0: Error: Failed to get PRSC status

Best,
Jonathan

Jonathan,

Usually when we get PRSC errors they turn out to be an issue with the way things are connected on a custom board.

Hope you are using the right target configuration for  xds100v2 debugger. Please make sure you're not using the older target configuration meant for TI onboard Emulator.

PRSC is a DLL that loaded and used by the TI emulation software that provides parent status for a processor.  In certain devices it requires to read some registers from the emulation circuitry inside the device. If it failed to read the registers or the registers contained unexpected values then that could cause the error message you are seeing. 

Therefore I would check the General IDE and the Debugger troubleshooting steps in the page below to be sure:

http://processors.wiki.ti.com/index.php/Troubleshooting_CCS

The next step I would do is reduce the speed of the JTAG clock. Check the quick tip below that shows how to do this:

http://software-dl.ti.com/dsps/dsps_public_sw/sdo_ccstudio/CCSv4/Demos/ccs4-setup2_b5.htm

Please try this and let us know 

Regards

Antony  

Hi Antony,

Thanks for your quick reply!  I'll let you know the results once I have access to our board tomorrow.  

However, I don't have very high hopes, since I have tried the same procedure and configuration (xds100v2 + gel file) with the Spectrum Digital EVMAM1707 board, and the error does not occur...

Could this behavior be caused by a hardware bug on our custom board?  To answer your previous query, our hardware engineer says that the OSCIN, power, and reset signals all look fine.

Best,
Jonathan 

Hello, Antony,

I tried the steps you recommended, but nothing seemed to help:

• ccstudio.exe -clean: error still occurs
• delete .metadata: error still occurs
• dbgjtag.exe: all tests passed (see attached log)
• slower JTAG TCLK (Target Configuration > Advanced): error still occurs even at 0.01 MHz

Please note that the error never occurs with the same configuration (xds100v2 + gel file) and the Spectrum Digital EVMAM1707 board; I suspect that the problem lies in our custom board hardware, but we are not sure where to start looking...

Thanks!
Jonathan

Hi Jonathan,

Seems like this issue will need specific help from the Emulation experts. I am moving this post to the forum that deals with such issues but we will monitor the thread in case Antony's inputs are needed.

Regards,

Sunil

Thank you, Sunil!

I would just like to add that our problem is not necessarily emulation-specific, as similar behavior occurs using AISgen to configure PLL.  

In this case, using UartBoot.exe (no JTAG emulator at all), bootup hangs on the opcode corresponding to PLL and Clock Configuration (spraba4c.pdf p. 31).  Again, this only occurs on our custom board, and not on the Spectrum Digital EVMAM1707 evaluation board.

-Jonathan

Hi Jonathan,

Jonathan Chen said:

I would just like to add that our problem is not necessarily emulation-specific, as similar behavior occurs using AISgen to configure PLL.  

This certainly does take the spotlight away from emulation.

I would recommend going through the the following Wiki site:http://processors.wiki.ti.com/index.php/OMAP-L137_Hardware_Design_Guide, the Spectrum Digital schematics and the RESET timing requirements (from AM1705 datasheet) as a first step focusing on POR and clock circuitry and compare them with those captured from your custom board.

You can also run the debug gel file (http://processors.wiki.ti.com/index.php/OMAP-L1x_Debug_Gel_Files) after the boot failure and attach the console output to your next post. This will give us some more informationto go by.

Rgds,

Sunil

Hello, Sunil,

Thank you for the helpful link!  I will be sure to keep you posted if our hardware engineer makes any breakthroughs and/or runs into any problems.

Here is the output from OMAPL1x_debug.gel when the board boots UartHost.exe (with "Configure PLL" checked in AISgen):

ARM9_0: GEL Output: ---------------------------------------------
ARM9_0: GEL Output: |             Device Information            |
ARM9_0: GEL Output: ---------------------------------------------
Run_All() cannot be evaluated.
Target failed to read memory at 0x01C14018

When the board boots from my gel file (which calls Setup_PLL()), the last line is slightly different:

...
Run_All() cannot be evaluated.
target is not connected

Edit: attached OMAPL1x_debug.gel output when the board boots with PLL kept in bypass mode.

Best,
Jonathan

Could this problem be caused by an insufficiently filtered PLL0_VDDA?

The inductors and capacitors on p. 44 of the AM1705 datasheet are there, but the input 1.2V power supply is not as filtered as the reference design (1.2V directly from TPS65023 instead of 3.3V to TPS79901 to 1.2V)

Hi Jonathan,

It’s been a long time; I wish I didn’t have to put you in this position and debugging this issue for the last six months.

Are you still debugging the same board?

How many prototype you’ve assembled so far for the same revision?

Have you tested the GEL script on other custom board of same revision apart from EVMAM1707?

How do you arrive at the point of insufficiently filtered PLL0_VDDA?

Can you send the AM1705 schematics page for further investigation on the PLL0_VDDA?

if you don't want to post the schematics in the public forum , you can send us an E-mail – x0187392@ti.com

It's unique problem ,we never see this from other customer

Regards

Antony

Hello, Antony,

Good to hear from you again!  Don't worry, we just started looking at this again yesterday for the first time in *eight* months!

We are still on our first and only prototype, and we still don't have any other boards besides EVMAM1707.

I am considering PLL0_VDDA after comparing our hardware engineer's schematic with the EVMAM1707's.

Our schematic is on its way to your email!

Best,
Jonathan

More weirdness: Initializing our custom board with register PLLM <= 2 in the GEL file, PLL can somehow initialize cleanly!?  The interrupt-enabled uartEcho example from StarterWare seems to run just fine on our custom board at 72 MHz. 

Of course, we ultimately want to run at 456 MHz, but I thought I'd report this weird finding...

Details

• crystal frequency: 24 MHz
• yes, this PLLM value goes against *multiple* restrictions from the data sheet (sprs657c.pdf p. 46)
• with PLLM <= 2, the GEL file will hang on running SetPscAllOn() - but it executes to completion when only GPIO, EMIFB, and UART2 are powered on; there is almost certainly something wrong with our power circuitry
• uartEcho is finicky! interrupts at 72 MHz seem to require 115200 kbps baud rate, whereas interrupts at 24 MHz require 57600 kbps or LOWER!?
• PLLM = 3: GEL file runs to completion, but then loading code into SDRAM gives
  
  • ARM9_0: Trouble Writing Memory Block at 0xc1080000
  • ICEPICK_C: Error: (Error -150 @ 0x0) This utility failed to operate the adapter for a custom emulator.
• PLLM = 4: GEL file runs to completion, but then there are spontaneous error messages within a few seconds
  
  • Trouble Reading Memory Block at 0xfffd3654
  • (Error -1033 @ 0x3FF) Instruction bus is 'not ready'
  • Error -1060 Device is not responding to the request
  • Error -1029 Invalid data read from ICECrusher register
• PLLM = 5 to 8: PLLEN asserts, but the next GEL file action fails
  
  • Driver did not attempt to write memory at 0x01C14038.
  • Error: (Error -1029 @ 0x2B5F) Invalid data read from ICECrusher register
• PLLM = 9 to 31: GEL file hangs on asserting PLLEN

Hi Jonathan,

Follow Up on your schematics review, I see some of your notes in the schematics, hope you will fix the same in the upcoming revisions, we can’t figure out the reason for weirdness behavior in the PLLM value changes, until you fix all the other issues in the board.

JATG Section

Series termination resistor missed for TCK and RTCK signals, please refer the below wiki links for more details

http://processors.wiki.ti.com/index.php/XDS_Target_Connection_Guide#Non-buffered_JTAG_Signal_Termination

PLL Filtering

As discussed please take care of the PLL filtering circuit by referring the EVM schematics ,probably we have a separate LDO 1.2V to power the PLLA section ,but you can use the same CVDD supply but make sure you’ve filtered all the noise caused by the switching supplies.

Power Rails

I see there are lot of 0.25 ohm resistor across different power rails, make sure those resistance are less to avoid core voltage drop during power Up or inrush current

Reserved Pin connections

RSV2 connect to CVDD

RSV3 connect to CVDD

PSV4 connect to CVDD  

OSCILLATOR

Please the oscillator close the device pins, please refer the schematics check list for more details on the clocking requirement in the clocking section

http://processors.wiki.ti.com/index.php/OMAP-L13x_/_C674x_/_AM1x_Schematic_Review_Checklist#JTAG.2FEmulation

Power and GND planes

Ensure that you have a proper power and ground plane in your PCB, if you taking trace to connect VDD pins please make sure you have thicker trace width (20Mils), Make sure to check the soldering stencils or paste thickness for good contacts.

 Regards

Antony

Disclaimer:

In schematic review, only TI parts was reviewed which excludes review of symbol(pin name versus pin number) & review of regulatory (FCC,CE etc).

This schematic or layout review is provided for reference only, without warranty expressed or implied. The recipient is encouraged to perform all due diligence with respect to design and analysis. For committed performance and functionality of TI devices, please refer to the device’s Data Manual

Thank you, Antony!  I will forward your suggestions to our hardware engineer and let you know how it goes.

Best,
Jonathan

Jonathan,

Coming back to you on the PLLM settings , Please make sure the  multiplier values must be chosen such that the PLL output frequency (at PLLOUT) is between 300 and 600 MHz, but the frequency going into the SYSCLK dividers (after the post divider) cannot exceed the maximum clock frequency defined for the device at a given voltage operating point

Please refer the Table 5.5 Allowed Operating conditions in the datasheet for more details

Regards

Antony

Hello, Antony,

Thank you for your continued support.

For our normal testing, we use the following register values, taken from Spectrum Digital's evmam1707.gel:

    unsigned int CLKMODE =  0;
    unsigned int PLLM =    18;
    unsigned int POSTDIV =  0;
    unsigned int PLLDIV3 =  3;
    unsigned int PLLDIV5 =  3;
    unsigned int PLLDIV7 =  5;

With our 24 MHz crystal, this results in a VCO ("PLLOUT"?) of 456 MHz.

These settings work fine on the EVM, but our custom board will hang when asserting PLLEN.  The same behavior is observed on our custom board with PLLM = 9 to 31 (VCO = 240 to 768 MHz).

I will let you know what happens after our hardware engineer gets around to updating our custom board according to your previous suggestions.

Best,
Jonathan