C5515 USB PLL not working after DSP power on reset boot

Danimal

I am using the USB DMA example from the Low Power CSL 2.0 and created a bootable version of the application for the C5515 USB STICK.

I burned the application into NV memory and then configure the clockout pin.

The problem is that when the DSP boots from NVMEM the USB PLL is not running at all (CLKOUT High with CLKOUT enabled and CCSSR.SRC=0xF)

Setting CCSSR.SRC=0xB I can see the sysclk running at 120 MHz.

When I load the same code via code composer and the out of the box .gel scripts the application runs correctly and the USB PLL is observed to run at 60 MHz.

___

8/16 1PM update

I've tried CCSSR.SRC=0x7 as well after the DSP boot and get the same result. The USB_init() code does not appear to match the recommended steps in the USB user guide or the DSP user guide. In fact both these documents contradict each other for the proper steps to initialize the USB.

Section 1.4.3 of the http://www.ti.com/lit/ug/sprufx6/sprufx6.pdf

To enable the USB clock domain, follow these steps:

1. Enable the USB oscillator by setting USBOSCDIS = 0 in USBSCR.

2. Wait for the oscillator to stabilize. Refer to the device-specific data manual for oscillator stabilization

time.

3. Enable the USB peripheral clock by setting USBCG = 0 in the peripheral clock gating control register 2

(PCGCR2).

4. Clear the USB clock stop request bit (USBCLKSTREQ) in the CLKSTOP register.

5. Clear the SUSPENDM bit in FADDR register.

The USB user guide http://www.ti.com/lit/ug/sprugh9/sprugh9.pdf has:

The detailed USB PHY initialization sequence

is as follows:

1. The bits USBOSCBIASDIS and USBOSCDIS in the USB system control register (USBSCR) should be

cleared to 0 to enable the on-chip USB oscillatory if not enabled already.

2. Wait cycles for the on-chip oscillator to stabilize. Refer to the device-specific data manual for oscillator

stabilization time.

3. To configure the PHY for normal operation, the bits USBPWDN, USBSESSEND, and USBPLLEN in

USBSCR should be cleared to 0, the USBVBUSDET bit should be set to 1, and the USBDATPOL bit

should be set according to the system requirements (set to 1 for normal operation).

4. Enable the USB clock by clearing USBCG to 0 in the peripheral clock gating configuration register 2

(PCGCR2).

5. Set the USBCLKSTPREQ bit.

6. Set COUNT = 20h in the peripheral software reset counter register (PSRCR).

7. Reset the USB controller by setting USB_RST to 1 in the peripheral reset control register (PRCR). This bit will self-clear once the reset has been completed.

Not sure if this could be more confusing. One document says to clear USBCLKSTPREQ and the other says to set USBCLKSTPREQ .

In either case, I run through these steps and cannot get the USB PLL to output 60 MHz. I've tried the code on another USB stick board and get the same results. It's as if the TI Bootloader puts the USB controller into a non-recoverable state.

Is there a USB PLL loss of lock status indicator?

Is there a limitation on the number of times the PLL register can be configured or some other protection? (I've seen this on other processor, but cannot find if this exists on the DSP)

Any help is greatly appreciated.

over 14 years ago

0 Wen Li over 14 years ago

TI__Expert 5301 points

In your boot-able program, have you integrated the PLL settings part? Just like what it does in the GEL file, your C program needs to do the same thing.

Regards

Wen

0 Danimal over 14 years ago in reply to Wen Li

Expert 1135 points

Yes, vector.asm configures the PLL for 120 MHz and does a 4 msec delay per the specs.     ; 1. Force to BYPASS mode in CCR2. SYSCLKSEL=0
    *port(#CONFIG_MSW) = #0x0;    ; *(short *)CCR2@IO = 0x0;
    ; use these settings when 32768 Hz oscillator is clock reference
    ; 2. CGCR1 CLR_CTRL = 0 disable PLL
    *port(#PLL_CNTL1) = *port(#PLL_CNTL1) & #0x7fff;   ; *(short *)CGCR1@IO = *(short *)CGCR1@IO & 0x7FFF;

    ; PLL settings for 120 MHz
    ; 3 CGCR2 (aka CGICR) bit RDRATIO=0, and RDBYPASS=1 to bypass input divider (Note. M will be set later just like CSL)
    *port(#PLL_CNTL2) = #0x8000; ;*(short *)CGCR2@IO = 0x8000;

    ; 4. CGCR4 (aka CGOCR) bits ODRATIO=0 divider=0+1, OUTDIVEN=0 to disable output divider
    *port(#PLL_CNTL4) = #0x0000; ;*(short *)CGCR4@IO = 0x0000;

    ; 5. CGCR3 bits INIT=0x0806   (same as CGCR2 0x1c22 in CSL note the CSL overloaded name)
    *port(#PLL_CNTL3) = #0x0806; ;*(short *)CGCR3@IO = 0x0806;

    ; 6. CGCR1 bits CLR_CTRL=1 normal operation, PLL_PWRDN=0 to power up PLL, M=E4B (3659) Mult=M+4=3663 with input clock of 32768 gives 120.029184 MHz
    *port(#PLL_CNTL1) = #0x8E4B; ;*(short *)CGCR1@IO = 0x8E4B;
    ; 7. Wait at least 4 ms for PLL lock
    ; Note. The 32768 Hz with worst case +/- 5% error = 34406
    ; 34406 Hz * .004 sec = 138 ticks / 2 for each instruction = 69
    ; Uint16 timeout = 0x7FFF;
    ; while ( !(PLL_CNTL3 & 0x0008) && (timeout--) );

    AR1 = #0x69;
loop_PllSwDelay:
    AR1 = AR1 - #1;
    if (AR1 != #0) goto loop_PllSwDelay;
loop_PllSwDelayEnd;

;8. CCR2 set SYSCLKSEL=1 to switch to PLL clk
*port(#CONFIG_MSW) = #0x1; ;*(short *)CCR2@IO = 0x1;

As indicated in the original post. I probe the clockout pin after the bootloader loads and runs the code and I see the CLKOUT signal is 120 MHz.

The sequence that I'm using to troubleshoot this issue is as follows:

1. I build by application and create the .bin file

2. i use the nor_writer application to program the flash memory on the C5515 usb stick

3. I then download the usb sample application into RAM as normal.

4. I click the DSP reset icon to go to the entry point of the bootloader.

5. I click run and then press pause. The program counter is at my main() that looks like

static volatile mbPause = 1;

void main(void) {

while (mbPause) {

}

// the rest of the USB example code here..

}

6. Using the debugger I change mbPause = 0 and then step through the code.

7. CLKout for the SYSCLK at this point is 120MHz, CLKOUT for the usb pLL at this point is 0 MHz.

8. I step through the USB_Init() call and the USB PLL is still at 0 MHz.

Simple stuff. Why does this not work. Both stacks look good. I look at the USB registers and everything looks like it should be running, but don't.

I can terminate the debug session. Download the same exact application via code composer and after the step through USB_Init() the USB clockout is at 60 MHz.

Why??

0 Danimal over 14 years ago in reply to Danimal

Expert 1135 points

I tracked the problem down to the silicon of the DSP.

I compared the register values for sate 1. the good working code composer versus the state 2. failed to run after bootloader. A number of registers are different, bu the one that caught my attention was the PCGCR1 and PCGCR2 register values. In state 1 code composer has PCGCR1=0 and PCGCR2=0 for a configuration with all peripherals enabled. In state 2 after bootloader execution PCGCR1=0xFFFF and PCGR2-0x7F indicating that all peripheral clocks have been disabled.

It appears that having PCGCR2[ANAREGCG]=1 and PCGCR2[USBCG]=0 prevents the USB PLL from locking. Having PCGCR2[ANAREGCG]=0 and PCGCR2[USBCG]=0 is required to get the USB PLL to lock. However, there is a delay required when programming the PCGCR2 register.

Here's what I've found to work:

1. PCGCR2[ANAREGCG]=0

2. delay 1 usec

3. Then call USB_init() which will internally configure PCGCR2[USBCG]=0

I tested the code with this and have found no issue. Without step 1 & 2 the USB PLL will not lock. I've also verified this problem exists on 2 other boards and with this fix in place the USB PLL locks. I've also tested with just the delay in place without step 1 and the USB will not lock.

My DIEIDR0..7 registers are as follows: D029, 0600,26B2,068D,0,0,0,246A

Why does step 1 and 2 need to be done for the USB PLL to lock?

Processors

Processors forum

C5515 USB PLL not working after DSP power on reset boot