Running StarterWare USB on Customer

This is my question.  Additional information :

I'm running on the C6748 core of the OMAP-L138.  Nothing is currently running in the ARM.  

The board is our own hardware that we've used before.  But we've never used the USB.  Now, I need to use it super-quick.

I'm wondering if there is something with respect to the clocking of the OMAP that would cause this to stall on a PLL check?  Due to other design constraints, pin L19 (OMAP OSCIN) is driven by a 25 MHz clock.  Maybe I need to change some PLL settings to make the USB PHY happy?  I know USB on TI parts often takes a 24 MHz clock.  

Any ideas, smart folks?  Thanks!

Hi 

It is stuck  USB0PHYCLKGD Status of USB2.0 PHY.
0 Clock is not present, power is not good, and PLL has not locked.
1 Clock is present, power is good, and PLL has locked.

Please check table 7-4 in SPRUH77A for the recommended clocking schemes and supported USB clocks (via PLL0_AUXCLK or REFCLKIN externally)

25 MHz is not supported, and does not allow the on chip USB PLL to generate the desired clocks. 

Can you blue wire to test with a supported frequency listed in the device clocking chapter to see if it fixes the issue?

Regards

Mukul 

Yeah.  The 25MHz system clock was an effort to max out EMIF speeds where we have an FPGA hooked up streaming us a ton of data.  I'll get with the board designer and get that swapped out.

Alright, I'm back.  I've replaced the external 25 MHz oscillator on the board with a brand new 24 MHz part.  Still no joy on the USB2.0 section.

Looking at The CFGCHIP2 Register in the register view, I have the following.

CFGCHIP2	0x000109F2	Chip Configuration 2 Register [Memory Mapped]	
	_RESV_1	**************	Reserved	
	USB0PHYCLKGD	0	Reports status of USB 2.0 PHY.  Clock is present, power is good, pll locked	
	USB0VBUSSENSE	1	Reports status of USB 2.0 PHY VBUS detection	
	RESET	0	Places USB 2.0 PHY in reset	
	USB0OTGMODE	00 - PHY	what USB2.0 PHY comparators are used to drive	
	USB1PHYCLKMUX	0 - USBCLK	Controls USB1 PHY reference clock input mux	
	USB0PHYCLKMUX	1 - EXTCLK	Controls USB2 PHY reference clock input mux	
	USB0PHYPWDN	0	Power down USB 2.0 PHY	
	USB0OTGPWRDN	0	Power down USB 2.0 OTG Subsystem	
	USB0DATPOL	1	Select data polarity of USB 2.0 OTG subsystem	
	USB1SUSPENDM	1 - ENABLED	Controls USB1 Suspend mode	
	USB0PHY_PLLON	1	Turn on/off USB PLL	
	USB0SESNDEN	1	Turns on Session End comparator	
	USB0VBDTCTEN	1	Turns on VBUS line comparators	
	USB0REF_FREQ	0010	Configure USB PHY for different reference clock input frequencies	

So, it's on.  It sees the VBUS on the line.  It's configured for an external 24 MHz oscillator.  What else do I need to do?

I thought that I might need to fiddle with the system PLL0 and PLL1, but looking at the clocking topology, it looks like the 24MHz external clock heads straight to the USB subsection. 

Hello FastFourier,

Thanks for providing the CFGCHIP2 Register values.

What is the clock value at pin L19 (OMAP OSCIN) ?

Are you using separate crystal for OSCIN and USB_REFCLKIN ?

Since i'm seeing the USB0PHYCLKMUX value as 1, the USB2.0 subsystem has taken the AUXCLK instead of USB_REFCLKIN. Please refer figure 35.2 in SPRUH77A.

In PLL architecture, the AUXCLK is derived from the internal oscillator (in your case). If you are using non-supported clock at pin L19, the USB PLL does not recognize the clock.

Otherwise, you can also rewrite the USB0PHYCLKMUX value to 0 and check.

Regards,
Senthil

Hi Fourier,

For 24 MHz,

Your USB2.0 configurations seems to be good for USB AUXCLK clock.

USB0REF_FREQ = 0010

USB0PHYCLKMUX   1

Try to the below code,

void UsbPhyOn()
{

    unsigned int  reg = 0;

	reg = HWREG(CFGCHIP2_USBPHYCTRL); 

    reg &= ~(CFGCHIP2_RESET | CFGCHIP2_PHYPWRDN | CFGCHIP2_OTGPWRDN);   

    reg |= CFGCHIP2_PHY_PLLON;

#ifdef USB_MODE_HS_DISABLE
	HWREGB(USB0_BASE + USB_O_POWER) &= 0xdf;
#endif /* USB_MODE_HS_DISABLE  */

/* Titus Debug */

    reg = 0x09F2; //Got from gel file

    HWREG(CFGCHIP2_USBPHYCTRL) = reg;

    while (!(HWREG(CFGCHIP2_USBPHYCTRL) & CFGCHIP2_PHYCLKGD)); 
	
}

Please answer the following questions to understand your background to support better.

What is your reference board for your custom board ?

What are all the changes have you been made in custom from USB part (clocking) ?

What type of starterware USB examples are you running (host mass storage or device mass storage etc.,) ?

Have you modified the USB drivers and examples code ?

If you modified the USB drivers then you have re-compile the USB driers to get effect in USB examples.

Are you running this examples through CCS ?

I presume that you are not getting any issues while loading gel file and ARM/DSP initializing when we used the 24MHz crystal,

Have you modified the gel file when you used 25MHz & 24 MHz ?

or simply used the same gel file provided by TI

Hi Ronald,

In addition to Titus's points, would you please check that the PSC1 is configured properly for USB0? which enables the clocking for the module

In the code, Can you check the return value of PSCModuleControl API

PSCModuleControl(SOC_PSC_1_REGS,1, 0, PSC_MDCTL_NEXT_ENABLE);

Regards,

Shankari

-------------------------------------------------------------------------------------------------------

Please click the Verify Answer button on this post if it answers your question.
--------------------------------------------------------------------------------------------------------

Hi everyone.  Thanks for the responses.

Senthi Kumar Srinivasan

1. L19, OSCIN has a +1.1V 24 MHz clock driven to it.  I had the HW engineer replace the 25 MHz clock.

2. We do not have a separate USB_REFCLKIN oscillator populated.

3. I was setting USB0PHYCLKMUX to 1 and USB0_FREQ to 0010 so that I could use the OSCIN 24 MHz clock mentioned in #1 above.  If I understand correctly, this should use the AUXCLK internally and select the 24MHz input.

4. I put a scope on the output of the 24 MHz clock driver and measured its frequency.  It's a nice stable 24 MHz.

5. I tried selecting the internal clock via writing USB0PHYCLKMUX to 0 yesterday.  I got no lock that way either.

Titus Rathinaraj Stalin

1. Our board is very loosely based on the LCDK board.  But really, there's not much similarity.  We have an FPGA on there.  We have an RF section attached to the FPGA.  The FPGA connects to the DSP via EMIF.  The 25MHz clock was there to make hitting some FPGA PLL frequencies possible.  (The HW designer didn't want to put two clocks on the boards... I don't know why.)  We have a uart to USB chip on there which I'm not using at the moment.  It was put on for booting via a USB connection.  But that hooks up to one of the UARTs and not USB0 or USB1.  Most of the peripherals, however, we don't need.  We don't use a display.  No SATA.  No ethernet.  But now we need high speed USB, so I'm working on getting that up and running.

2. We had a 25MHz clock at first.  I just swapped that out for a 24 MHz part.  USB_REFCLK is unconnected.

3. I'm trying to run the usb bulk code.  I looked at the USB bulk example and worked it into our project.

4.a. I have not modified the drivers, however, I did rebuild them recently to support DMA to get higher data rates.  I was already experiencing this particular issue before I rebuilt it though.  That rebuild just defined BULK_DMA_MODE and then built. 

4.b. I worked the relevant code from the usb bulk device example into my project code.  There certainly could be something missed in there, and in a bit, when I finish responding to this, I'll try the bulk example directly, without modification.

5. CCSv6

6. The 25 MHz oscillator required changes to the GEL file to hit the right frequencies, but I was undoing those yesterday.  I used the spreadsheet TI published for calculating the new values.  I've tried to use the TI-provided GEL files but I haven't been able to get all the way to main with them.  I haven't diagnosed that problem completely yet.  I had assumed that it had something to do with peripherals etc etc.

Shankari G

int retVal;

retVal = PSCModuleControl(SOC_PSC_1_REGS,1, 0, PSC_MDCTL_NEXT_ENABLE);

retVal is 0 after that call.  I don't know what that means.  But PSC1 could need configuring.  Where do I find it and what value should it have?

Does pin muxing need to be setup in any certain way for USB0 to be alive?  That may need to happen still.  I have gone through the previous engineer's code and converted all of the pinmux'ing from things like HWREG() = 0x44444444; to the following in an effort to make it more readable/maintainable for me.

    /* PinMux0 setup.  UART2 and GPIO 10, 12, 13 and 14. */
    pin_mux = (SYSCFG_PINMUX0_PINMUX0_31_28_UART2_CTS << SYSCFG_PINMUX0_PINMUX0_31_28_SHIFT) | \
    		  (SYSCFG_PINMUX0_PINMUX0_27_24_UART2_RTS << SYSCFG_PINMUX0_PINMUX0_27_24_SHIFT) | \
    		  (SYSCFG_PINMUX0_PINMUX0_23_20_GPIO0_10  << SYSCFG_PINMUX0_PINMUX0_23_20_SHIFT) | \
    		  (SYSCFG_PINMUX0_PINMUX0_19_16_DEFAULT   << SYSCFG_PINMUX0_PINMUX0_19_16_SHIFT) | \
    		  (SYSCFG_PINMUX0_PINMUX0_15_12_GPIO0_12  << SYSCFG_PINMUX0_PINMUX0_15_12_SHIFT) | \
    		  (SYSCFG_PINMUX0_PINMUX0_11_8_GPIO0_13   << SYSCFG_PINMUX0_PINMUX0_11_8_SHIFT ) | \
    		  (SYSCFG_PINMUX0_PINMUX0_7_4_GPIO0_14    << SYSCFG_PINMUX0_PINMUX0_7_4_SHIFT  ) | \
    		  (SYSCFG_PINMUX0_PINMUX0_3_0_DEFAULT     << SYSCFG_PINMUX0_PINMUX0_3_0_SHIFT  );
    /* Check that we actually got what we expected from the macros */
    if( PINMUX0_VALUE != pin_mux )
        return false;
    /* Write it out. */
    HWREG(CSL_SYSCFG_0_REGS + SYSCFG0_PINMUX(0)) = pin_mux;

And there are a ton of those.

I do see the following in the GEL file regarding PSC1 in the "Experimenter all on" function, which I have called from the pull down menu.

    PSC1_LPSC_enable(0, LPSC_USB20);
    PSC1_LPSC_enable(0, LPSC_USB11);
    CFGCHIP2 = 0x09F2;  // Enable USB clock, PHY_PLLON, glue logic mux(USB2 ref clk input)

Attached is my GEL file.

8371.C6748_mine.gel

I just tried to run the usb_dev_blk_c674x_c6748_lcdkC6748 example from the Starterware directory, using CCSv6.  I created a target config for my Spectrum Digital XDS560v2 USB JTAG pod.  I selected a C6748 device.  I used the GEL file in...

Starterware_ROOT/tools/gel/C6748.GEL

Unfortunately, it doesn't break at main.  It's off running in hex land, and I'm not sure why it's not happy.  Frankly, I don't know much about GEL files and chip initialization.  "I'm a DSP guy!"  :)  I'm trying here. 

Maybe one of you knows what could be wrong.

Hello,

If supplying an external clock to the OSCIN pin make sure it is of the correct amplitude 1.2V.,Just be curious you're seeing  1.1V make sure you make this modification before going for production.

Please check the datasheet and schemaics chek list for more details

http://processors.wiki.ti.com/index.php/OMAP-L13x_/_C674x_/_AM1x_Schematic_Review_Checklist

Regards

Antony

Hi Fast Fourier,

I have tried out the usb_dev_blk_c674x_c6748_lcdkC6748 on C6748 LCDK board and it breaks at main. Screenshot attached below. By some chance, if  you have a C6748 LCDK board with you, please try out the same example on it which may give us some difference between the custom board and the LCDK board. This might gives us a clue to find the root cause.

Regards,

Shankari

-------------------------------------------------------------------------------------------------------

Please click the Verify Answer button on this post if it answers your question.
--------------------------------------------------------------------------------------------------------

Hi Fast fourier,

For the problem of CCS, not breaking at main, try this solution. ( This solution worked for me!!  for different project with different EVM))

Try building the project, "usb_dev_blk_c674x_c6748_lcdkC6748" again by changing the compiler version as TI v5.1.1 and output format as "legacy COFF". Post the errors if not able to build it successfully. We will help you out !!. Tracking through the errors will also lead to do the same changes on dependency projects too.

This problem will occur when you try to run the example projects built for LCDK on EVM and vice versa. I mean to say, if you try to run the "usb_dev_blk_c674x_c6748_lcdkC6748" on C6748 EVM instead of C6748 LCDK, this problem will occur. So, make sure that the appropriate projects are imported.

Regards,

Shankari

-------------------------------------------------------------------------------------------------------

Please click the Verify Answer button on this post if it answers your question.
--------------------------------------------------------------------------------------------------------

I pulled out my old LCDK board, and ran the usb_dev_bulk_c674x_c6748_lcdkC6748 example project.  

First, it breaks at main just fine, unlike on my hardware with this same code.

Second, I'm able to step through and call USBDBulkInit without the board hanging.

So, the demo works on demo hardware.  It doesn't work on our custom hardware.  I wish I could run the demo on our hardware and break at main.  I don't know how to troubleshoot that issue.

OK. I'm not sure what this does, but I'll give it a try. I have the LCDK 6748 board. I built the usb_dev_bulk_c674x_lcdkC6748 project with nothing changed and ran in on the LCDK and it ran fine. Then, as you instructed, I changed the binary to Legacy COFF. I rebuilt. Here are all of the errors.

**** Clean-only build of configuration Debug for project usb_dev_bulk_c674x_c6748_lcdkC6748 ****

/opt/CCSv6/ccsv6/utils/bin/gmake -k clean 
rm -rf  "usb_dev_bulk.out" 
rm -rf "usb_bulk_structs.pp" "usb_dev_bulk.pp" "ustdlib.pp" 
rm -rf "usb_bulk_structs.obj" "usb_dev_bulk.obj" "ustdlib.obj" 
Finished clean
 

**** Build Finished ****

**** Build of configuration Debug for project usb_dev_bulk_c674x_c6748_lcdkC6748 ****

/opt/CCSv6/ccsv6/utils/bin/gmake -k all 
Building file: /opt/CCSv6/C6748_StarterWare_1_20_03_03/examples/lcdkC6748/usb_dev_bulk/usb_bulk_structs.c
Invoking: C6000 Compiler
"/opt/CCSv6/ccsv6/tools/compiler/c6000_7.4.8/bin/cl6x" -mv6740 -g --gcc --define=c6748 --include_path="/opt/CCSv6/ccsv6/tools/compiler/c6000_7.4.8/include" --include_path="../../../../../../../examples/lcdkC6748/usb_dev_bulk" --include_path="../../../../../../../include" --include_path="../../../../../../../include/hw" --include_path="../../../../../../../include/c674x" --include_path="../../../../../../../include/c674x/c6748" --include_path="../../../../../../../grlib/include" --include_path="../../../../../../../usblib/include" --include_path="../../../../../../../ipclite/include" --include_path="../../../../../../../nandlib/include" --diag_warning=225 --abi=coffabi --preproc_with_compile --preproc_dependency="usb_bulk_structs.pp"  "/opt/CCSv6/C6748_StarterWare_1_20_03_03/examples/lcdkC6748/usb_dev_bulk/usb_bulk_structs.c"
Finished building: /opt/CCSv6/C6748_StarterWare_1_20_03_03/examples/lcdkC6748/usb_dev_bulk/usb_bulk_structs.c
 
Building file: /opt/CCSv6/C6748_StarterWare_1_20_03_03/examples/lcdkC6748/usb_dev_bulk/usb_dev_bulk.c
Invoking: C6000 Compiler
"/opt/CCSv6/ccsv6/tools/compiler/c6000_7.4.8/bin/cl6x" -mv6740 -g --gcc --define=c6748 --include_path="/opt/CCSv6/ccsv6/tools/compiler/c6000_7.4.8/include" --include_path="../../../../../../../examples/lcdkC6748/usb_dev_bulk" --include_path="../../../../../../../include" --include_path="../../../../../../../include/hw" --include_path="../../../../../../../include/c674x" --include_path="../../../../../../../include/c674x/c6748" --include_path="../../../../../../../grlib/include" --include_path="../../../../../../../usblib/include" --include_path="../../../../../../../ipclite/include" --include_path="../../../../../../../nandlib/include" --diag_warning=225 --abi=coffabi --preproc_with_compile --preproc_dependency="usb_dev_bulk.pp"  "/opt/CCSv6/C6748_StarterWare_1_20_03_03/examples/lcdkC6748/usb_dev_bulk/usb_dev_bulk.c"
Finished building: /opt/CCSv6/C6748_StarterWare_1_20_03_03/examples/lcdkC6748/usb_dev_bulk/usb_dev_bulk.c
 
Building file: /opt/CCSv6/C6748_StarterWare_1_20_03_03/examples/lcdkC6748/usb_dev_bulk/ustdlib.c
Invoking: C6000 Compiler
"/opt/CCSv6/ccsv6/tools/compiler/c6000_7.4.8/bin/cl6x" -mv6740 -g --gcc --define=c6748 --include_path="/opt/CCSv6/ccsv6/tools/compiler/c6000_7.4.8/include" --include_path="../../../../../../../examples/lcdkC6748/usb_dev_bulk" --include_path="../../../../../../../include" --include_path="../../../../../../../include/hw" --include_path="../../../../../../../include/c674x" --include_path="../../../../../../../include/c674x/c6748" --include_path="../../../../../../../grlib/include" --include_path="../../../../../../../usblib/include" --include_path="../../../../../../../ipclite/include" --include_path="../../../../../../../nandlib/include" --diag_warning=225 --abi=coffabi --preproc_with_compile --preproc_dependency="ustdlib.pp"  "/opt/CCSv6/C6748_StarterWare_1_20_03_03/examples/lcdkC6748/usb_dev_bulk/ustdlib.c"
Finished building: /opt/CCSv6/C6748_StarterWare_1_20_03_03/examples/lcdkC6748/usb_dev_bulk/ustdlib.c
 
Building target: usb_dev_bulk.out
Invoking: C6000 Linker
"/opt/CCSv6/ccsv6/tools/compiler/c6000_7.4.8/bin/cl6x" -mv6740 -g --gcc --define=c6748 --diag_warning=225 --abi=coffabi -z -m"usb_dev_bulk_c674x_c6748_lcdkC6748.map" --warn_sections -i"/opt/CCSv6/ccsv6/tools/compiler/c6000_7.4.8/lib" -i"/opt/CCSv6/ccsv6/tools/compiler/c6000_7.4.8/include" -i"../../../../../../../binary/c674x/cgt_ccs/c6748/drivers/Debug" -i"../../../../../../../binary/c674x/cgt_ccs/c6748/lcdkC6748/platform/Debug" -i"../../../../../../../binary/c674x/cgt_ccs/c6748/system_config/Debug" -i"../../../../../../../binary/c674x/cgt_ccs/c6748/ipclib/Debug" -i"../../../../../../../binary/c674x/cgt_ccs/c6748/usblib/Debug" -i"../../../../../../../binary/c674x/cgt_ccs/utils/Debug" -i"../../../../../../../binary/c674x/cgt_ccs/grlib/Debug" -i"../../../../../../../binary/c674x/cgt_ccs/nandlib/Debug" --reread_libs --xml_link_info="usb_dev_bulk_linkInfo.xml" --rom_model -o "usb_dev_bulk.out"  "./ustdlib.obj" "./usb_dev_bulk.obj" "./usb_bulk_structs.obj" "../usb_dev_bulk.cmd" -l"libc.a" -ldrivers.lib -lutils.lib -lplatform.lib -lsystem_config.lib -lusblib.lib -lgrlib.lib 
warning: library
<Linking>

>> Compilation failure
   "../../../../../../../binary/c674x/cgt_ccs/c6748/drivers/Debug/drivers.lib"
   contains ELF object files which are incompatible with the TI-COFF output
   file.  Ensure you are using the proper library.
warning: library
   "../../../../../../../binary/c674x/cgt_ccs/utils/Debug/utils.lib" contains
   ELF object files which are incompatible with the TI-COFF output file.
   Ensure you are using the proper library.
warning: library
   "../../../../../../../binary/c674x/cgt_ccs/c6748/lcdkC6748/platform/Debug/pl
   atform.lib" contains ELF object files which are incompatible with the
   TI-COFF output file.  Ensure you are using the proper library.
warning: library
   "../../../../../../../binary/c674x/cgt_ccs/c6748/system_config/Debug/system_
   config.lib" contains ELF object files which are incompatible with the
   TI-COFF output file.  Ensure you are using the proper library.
warning: library
   "../../../../../../../binary/c674x/cgt_ccs/c6748/usblib/Debug/usblib.lib"
   contains ELF object files which are incompatible with the TI-COFF output
   file.  Ensure you are using the proper library.
warning: library
   "../../../../../../../binary/c674x/cgt_ccs/grlib/Debug/grlib.lib" contains
   ELF object files which are incompatible with the TI-COFF output file.
   Ensure you are using the proper library.
warning: library
   "../../../../../../../binary/c674x/cgt_ccs/c6748/drivers/Debug/drivers.lib"
   contains ELF object files which are incompatible with the TI-COFF output
   file.  Ensure you are using the proper library.
warning: library
   "../../../../../../../binary/c674x/cgt_ccs/utils/Debug/utils.lib" contains
   ELF object files which are incompatible with the TI-COFF output file.
   Ensure you are using the proper library.
warning: library
   "../../../../../../../binary/c674x/cgt_ccs/c6748/lcdkC6748/platform/Debug/pl
   atform.lib" contains ELF object files which are incompatible with the
   TI-COFF output file.  Ensure you are using the proper library.
warning: library
   "../../../../../../../binary/c674x/cgt_ccs/c6748/system_config/Debug/system_
   config.lib" contains ELF object files which are incompatible with the
   TI-COFF output file.  Ensure you are using the proper library.
warning: library
   "../../../../../../../binary/c674x/cgt_ccs/c6748/usblib/Debug/usblib.lib"
   contains ELF object files which are incompatible with the TI-COFF output
   file.  Ensure you are using the proper library.
warning: library
   "../../../../../../../binary/c674x/cgt_ccs/grlib/Debug/grlib.lib" contains
   ELF object files which are incompatible with the TI-COFF output file.
   Ensure you are using the proper library.

 undefined                  first referenced      
  symbol                        in file           
 ---------                  ----------------      
 _DelayTimerSetup           ./usb_dev_bulk.obj    
 _GrContextInit             ./usb_dev_bulk.obj    
 _GrOffScreen16BPPInit      ./usb_dev_bulk.obj    
 _GrRectDraw                ./usb_dev_bulk.obj    
 _GrRectFill                ./usb_dev_bulk.obj    
 _GrStringDraw              ./usb_dev_bulk.obj    
 _GrStringWidthGet          ./usb_dev_bulk.obj    
 _IntDSPINTCInit            ./usb_dev_bulk.obj    
 _IntEnable                 ./usb_dev_bulk.obj    
 _IntEventClear             ./usb_dev_bulk.obj    
 _IntEventMap               ./usb_dev_bulk.obj    
 _IntGlobalEnable           ./usb_dev_bulk.obj    
 _IntRegister               ./usb_dev_bulk.obj    
 _LCDPinMuxSetup            ./usb_dev_bulk.obj    
 _PSCModuleControl          ./usb_dev_bulk.obj    
 _RasterClearGetIntStatus   ./usb_dev_bulk.obj    
 _RasterClkConfig           ./usb_dev_bulk.obj    
 _RasterDMAConfig           ./usb_dev_bulk.obj    
 _RasterDMAFBConfig         ./usb_dev_bulk.obj    
 _RasterDisable             ./usb_dev_bulk.obj    
 _RasterEnable              ./usb_dev_bulk.obj    
 _RasterEndOfFrameIntEnable ./usb_dev_bulk.obj    
 _RasterFIFODMADelayConfig  ./usb_dev_bulk.obj    
 _RasterHparamConfig        ./usb_dev_bulk.obj    
 _RasterIntStatus           ./usb_dev_bulk.obj    
 _RasterLSBDataOrderSelect  ./usb_dev_bulk.obj    
 _RasterModeConfig          ./usb_dev_bulk.obj    
 _RasterNibbleModeDisable   ./usb_dev_bulk.obj    
 _RasterTiming2Configure    ./usb_dev_bulk.obj    
 _RasterVparamConfig        ./usb_dev_bulk.obj    
 _UARTStdioInit             ./usb_dev_bulk.obj    
 _USB0DeviceIntHandler      ./usb_dev_bulk.obj    
 _USBBufferDataWritten      ./usb_dev_bulk.obj    
 _USBBufferEventCallback    ./usb_bulk_structs.obj
 _USBBufferFlush            ./usb_dev_bulk.obj    
 _USBBufferInfoGet          ./usb_dev_bulk.obj    
 _USBBufferInit             ./usb_dev_bulk.obj    
 _USBBufferSpaceAvailable   ./usb_dev_bulk.obj    
 _USBDBulkInit              ./usb_dev_bulk.obj    
 _USBDBulkPacketRead        ./usb_bulk_structs.obj
 _USBDBulkPacketWrite       ./usb_bulk_structs.obj
 _USBDBulkRxPacketAvailable ./usb_bulk_structs.obj
 _USBDBulkTxPacketAvailable ./usb_bulk_structs.obj
 _g_sFontCm20               ./usb_dev_bulk.obj    
 _g_sFontCmss22b            ./usb_dev_bulk.obj    

error: unresolved symbols remain
error: errors encountered during linking; "usb_dev_bulk.out" not built
gmake: *** [usb_dev_bulk.out] Error 1
gmake: Target `all' not remade because of errors.

**** Build Finished ****

Hi Fast Fourier,

It is good to know that you are able to run the usb_dev_bulk_c674x_lcdkC6748 on C6748 LCDK. I am glad that you are able to break at main.

If at all, it doesnot break at main, I suggested to changing the binary into Legacy COFF as one of the solutions. That is not needed now as you are able to break at main on C6748 LCDK board.

Now,  you are trying to run the same project on your custom board. The first step is to notify the difference between the platform specific changes needed for your custom board with reference to the C6748 LCDK board and implement the changes.

(For example:- check the platform specific source and header files at .".\ti\OMAPL138_StarterWare_1_10_03_03\platform\lcdkOMAPL138" and ..\ti\OMAPL138_StarterWare_1_10_03_03\include\c674x\omapl138\lcdkOMAPL138.h )

Regards,

Shankari

-------------------------------------------------------------------------------------------------------

Please click the Verify Answer button on this post if it answers your question.
--------------------------------------------------------------------------------------------------------

Hi Fast fourier,

And also, you have to change the sub-dependency projects like drivers and libraries into legacy COFF binary format to eradicate the compilation failures.

Regards,

Shankari

-------------------------------------------------------------------------------------------------------

Please click the Verify Answer button on this post if it answers your question.
--------------------------------------------------------------------------------------------------------

OK.  I've gotten all of the dependent libs built into COFF format.  

FYI, let whoever put together the StarterWare Linux install know that the post-build steps which include Windows commands don't work well on Linux.  For example...

@mkdir  ..\..\..\..\..\..\binary\c674x\cgt_ccs\c6748\usblib\Debug & copy usblib.lib ..\..\..\..\..\..\binary\c674x\cgt_ccs\c6748\usblib\Debug\usblib.lib

should be

mkdir -p ../../../../../../binary/c674x/cgt_ccs/c6748/usblib/Debug & cp usblib.lib ../../../../../../binary/c674x/cgt_ccs/c6748/usblib/Debug/usblib.lib

That said, I've got it built as COFF.  First, I ran it on the LCDK board.  It does fine.  It breaks at main.  I'm able to init USB as a bulk device.  Everything works.

I went to our hardware and attempted the same.  Unfortunately, it doesn't break at main.  It landed in abort() in exit.c at line 128... the end of the function.  The call stack is empty, so I can't tell how it wound up here.

If I single step (F6), I find myself in extern void __interrupt c_int00() in boot.c.  If I single step again, instead of single stepping, it runs and never breaks.  If I pause it, I'm at hex 0x00712148, and no symbols are defined for that area.

How should I proceed?

FYI, when I use my modified GEL file, I'm able to run the bulk example on our hardware... to the point that it does break at main.  However, when I get to Bulk Init, and it calls "UsbPhyPn()", it hangs waiting for PLL lock.  (Those are the same symptoms I have in my project on our hardware.)

So, bulk example works in COFF mode on LCDK.  Bulk example does NOT work in COFF mode on my hardware.  The GEL files are different to get it to break at main.  The GEL files could be altering something that keeps the PLL from locking for USB.  (I posted the GEL file earlier in this thread.)  I don't know much about GEL files.

Hi Fourier,

Have you modified the "UsbPhyPn()" like below ?

Could you please try this code and let me know the results,

Please provide the value of USBPHYCTRL register.

void UsbPhyOn()
{
    unsigned int  reg = 0, reg1 = 0;
    reg = HWREG(CFGCHIP2_USBPHYCTRL);
    reg &= ~(CFGCHIP2_RESET | CFGCHIP2_PHYPWRDN | CFGCHIP2_OTGPWRDN);  
    reg |= CFGCHIP2_PHY_PLLON;
#ifdef USB_MODE_HS_DISABLE
    HWREGB(USB0_BASE + USB_O_POWER) &= 0xdf;
#endif /* USB_MODE_HS_DISABLE  */
/* Titus Debug */
    reg = 0x09F2; //Got from gel file
    HWREG(CFGCHIP2_USBPHYCTRL) = reg;

    reg1 = HWREG(CFGCHIP2_USBPHYCTRL);

    printf("USBPHYCTRL -> %p\n",reg1);

    while (!(HWREG(CFGCHIP2_USBPHYCTRL) & CFGCHIP2_PHYCLKGD));
    
}

From your modified gel,

Set_Core_450MHz() {
    device_PLL0(1,19,0,0,1,4,5);
    GEL_TextOut("\tPLL0 init done for Core:300MHz, EMIFA:90MHz\n","Output",1,1,1);
}

Are you using external oscillator ?

I think, this PLL settings were wrong for 450MHz,

If you are using 24MHz, you can't generate 450MHz, but 456MHz is possible.

Set_Core_456MHz() {
    device_PLL0(0,18,0,0,1,18,5);//PLLM = 18, POSTDIV=0 {24MHz * (18+1) / (1+0) = 456}
    GEL_TextOut("\tPLL0 init done for Core:456MHz, EMIFA:25MHz\n","Output",1,1,1);
}

If you are using 25MHz, then you should use like this.

Set_Core_450MHz() {
    device_PLL0(1,17,0,0,1,4,5);//PLLM = 17, POSTDIV=0 {25MHz * (17+1) / (1+0) = 450}
    GEL_TextOut("\tPLL0 init done for Core:450MHz, EMIFA:90MHz\n","Output",1,1,1);
}

Your modified gel file is configured for 500MHz which is out of spec (456=<) and not for 450MHz.

Titus,

       Thanks for the reply.  Regarding the GEL file, here's the situation.  We HAD a 25MHz external oscillator hanging off of OSCIN.  That was decided on, because the original team that worked on this board wanted max speed out of EMIF.  So they went with 25MHz and those GEL file settings.

       Earlier in this thread, I asked about that 25MHz oscillator and if it would be a problem for USB.  The answer was yes, so I had one of our techs replace it with a 24MHz oscillator which is on there now.  I've made the GEL file modifications you suggested to get 456 MHz from the 24MHz OSCIN via the PLLs.

      Here's my question regarding all of that; what settings in that GEL file should I use to get the max possible speed out of the EMIF at 456MHz CPU clock?  i.e. the line...

device_PLL0(0,18,0,0,1,18,5);

Does that give us something like 25MHz EMIF?  We're transferring a LOT of data from our FPGA via EMIF and it needs to be running as fast as possible.  Let me know on that one when you can.  Next post, USB.

I made the changes to the GEL file, and now am stepping through UsbPhyOn() with your modifications.  Here's what I find.

void UsbPhyOn()
{

    unsigned int  reg = 0, reg1 = 0;

    reg = HWREG(CFGCHIP2_USBPHYCTRL); /*reg is 0x000109F2 */

    reg &= ~(CFGCHIP2_RESET | CFGCHIP2_PHYPWRDN | CFGCHIP2_OTGPWRDN);   /*reg is 0x000109F2 */

    reg |= CFGCHIP2_PHY_PLLON;  /*reg is 0x000109F2 */

#ifdef USB_MODE_HS_DISABLE
	HWREGB(USB0_BASE + USB_O_POWER) &= 0xdf;
#endif /* USB_MODE_HS_DISABLE  */

    reg = 0x09F2; //Got from gel file  /*reg is 0x000009F2 */
    HWREG(CFGCHIP2_USBPHYCTRL) = reg;

    reg1 = HWREG(CFGCHIP2_USBPHYCTRL);  /*reg1 is 0x000109F2 */

    printf("USBPHYCTRL -> %p\n",reg1);  /* prints 109F2 */

    while (!(HWREG(CFGCHIP2_USBPHYCTRL) & CFGCHIP2_PHYCLKGD));
	
#if 0	
    HWREG(CFGCHIP2_USBPHYCTRL) = reg;

    while (!(HWREG(CFGCHIP2_USBPHYCTRL) & CFGCHIP2_PHYCLKGD)); 
#endif
}

Console : 

USBPHYCTRL -> 109f2

We don't have a USB ref clock.  We are just using the system main CPU clock, which is based off of a 24MHz external oscillator driving OSCIN.  Here is the register view (in CCS) of CFGCHIP2 while execution is at the line while(!(HWREG(CFGCHIP2_USBPHYCTRL) & CFGCHIP2_PHYCLKGD));

CFGCHIP2	0x000109F2	Chip Configuration 2 Register [Memory Mapped]	
	_RESV_1	**************	Reserved	
	USB0PHYCLKGD	0	Reports status of USB 2.0 PHY.  Clock is present, power is good, pll locked	
	USB0VBUSSENSE	1	Reports status of USB 2.0 PHY VBUS detection	
	RESET	0	Places USB 2.0 PHY in reset	
	USB0OTGMODE	00 - PHY	what USB2.0 PHY comparators are used to drive	
	USB1PHYCLKMUX	0 - USBCLK	Controls USB1 PHY reference clock input mux	
	USB0PHYCLKMUX	1 - EXTCLK	Controls USB2 PHY reference clock input mux	
	USB0PHYPWDN	0	Power down USB 2.0 PHY	
	USB0OTGPWRDN	0	Power down USB 2.0 OTG Subsystem	
	USB0DATPOL	1	Select data polarity of USB 2.0 OTG subsystem	
	USB1SUSPENDM	1 - ENABLED	Controls USB1 Suspend mode	
	USB0PHY_PLLON	1	Turn on/off USB PLL	
	USB0SESNDEN	1	Turns on Session End comparator	
	USB0VBDTCTEN	1	Turns on VBUS line comparators	
	USB0REF_FREQ	0010	Configure USB PHY for different reference clock input frequencies	

Hi Fourier,

      Here's my question regarding all of that; what settings in that GEL file should I use to get the max possible speed out of the EMIF at 456MHz CPU clock?  i.e. the line...

Does that give us something like 25MHz EMIF?  We're transferring a LOT of data from our FPGA via EMIF and it needs to be running as fast as possible.  Let me know on that one when you can.  Next post, USB.

As mentioned in gel file,

Great.  I just modified that GEL file, so we have ...

Set_Core_456MHz() {
    device_PLL0(0,18,0,0,1,5,5);
    GEL_TextOut("\tPLL0 init done for Core:300MHz, EMIFA:91MHz\n","Output",1,1,1);
}

Regarding USB, I'm having one of our techs replace the OMAP for me on that board.  I think it's unlikely that there is a problem with it, but why not eliminate va

Just got the board back with a new OMAP on it.  Still no USB PLL lock.  I'm using the GEL setting we just discussed.

Hi Fourier,

Could you please measure the SYSCLKx from CLKOUT pins to confirm that we configured the clocks correctly?

Are you able to any app (DSP or ARM) without any probelm on your custom board ?

Hello,

What is your core operating volatage 1.1 ,1.2 or 1.3V ? and OSCIN supply voltage ,hope you had 1.1V ?

Please confirm ....

Regards

Antony

Hi Fourier,

Thanks for your update.

Please update us once you got to fixed it.

I'm happy to report that powering the USB section did indeed give us a good PLL lock.  I am able to step past the line where PLL Good is checked.  When I look at the CHIPCFG2 register in the reg view, I see the bit set.  So all of that is good.

Just a general question.  My application is a SYS/BIOS application and I am now finding sticking points with the starterware code.  i.e. usbdenum.c line 539

        //
        // Wait about 100mS.
        //
		delay(100);

That never returns.  Should I go through and substitute SYS/BIOS constructs like...

Task_sleep(100);

in its place?  Is that safe to do with the StarterWare framework?  

Thanks for all of the help everybody.

Hi Fourier,

That never returns.  Should I go through and substitute SYS/BIOS constructs like...

Are you able to enter "delay" function when you do "step into" debugging?

No.  I get this error when I try.

Can't find a source file at "C:\GForge\starterware\dev\C6748_StarterWare_1_20_03_03\build\c674x\cgt\c6748\evmC6748\platform/../../../../../../platform/evmC6748/sysdelay.c"
Locate the file or edit the source lookup path to include its location.

And, considering I'm running Ubuntu Linux, I'm not surprised it can't find a file at C:\GForge... anything.

Hi Fourier,

Please locate the file in your starterware installation while CCS for prompt to locate.

If you give exact location sysdelay.c file while debugging then delay starts to work.

< Your starterware installation >/C6748_StarterWare_1_20_03_03\build\c674x\cgt\c6748\evmC6748\platform/../../../../../../platform/evmC6748/sysdelay.c"

fourier:~ $ locate sysdelay.c
/opt/CCSv6/C6748_StarterWare_1_20_03_03/platform/evmC6748/sysdelay.c
/opt/CCSv6/C6748_StarterWare_1_20_03_03/platform/lcdkC6748/sysdelay.c

So, how do I tell CCS where that file actually is?  See, delay is built into the platform library that I've linked, but CCS can't find the file when I go to step into it... because somewhere some coder hard coded a path in there to C:\GForge...

Where is that path hardcoded so that I can change it?

The StarterWare function delay() calls Sysdelay() which uses the HW timer. I would guess that SYS/BIOS is already using the HW timer. Best not to mess with it. I would say replace all delay() calls with SYS/BIOS calls.

So I swapped the call to "delay()" with Task_sleep();  It's odd.  I get the same behavior.  Task_sleep() hangs there as well.

More info.  I'm doing all of this USB setup and such from Task context.  Just a few lines further down into the code, I call Task_sleep(500) and it returns after a 500 msec delay.  Task_sleep(100) inside of the usbdenum.c never returns.  I single stepped it and found that...

    /* unlock task scheduler and block */
    Task_restore(tskKey);       /* the calling task will block here */

from line 553 in Task.c is where it goes out to lunch and never comes back.

I'm wondering if I need to do something more to make usblib SYS/BIOS friendly.  A call to Task_sleep() right outside of usblib calls works, but inside it fails.  All I did was add include paths to usblib's build project to get it to see Task.h.  I figured that since it would be linking into a SYS/BIOS project, it wouldn't need more than that.  Maybe that assumption was wrong.

Any thoughts anyone?

Further observation :

If I comment out that call to Task_sleep() in the usb setup, I get out of usb initialization just fine, but the following calls elsewhere in my code to Task_sleep() never return.  

If I comment out the usb setup entirely, Task_sleep() begins working again everywhere in my code.

What is usblib claiming/doing to make Task_sleep() blow up like this?  Is it timer related?  Is it taking the timer from SYS/BIOS maybe?

Hi Fourier,

Can't find a source file at "C:\GForge\starterware\dev\C6748_StarterWare_1_20_03_03\build\c674x\cgt\c6748\evmC6748\platform/../../../../../../platform/evmC6748/sysdelay.c"
Locate the file or edit the source lookup path to include its location.

CCS would open one window and ask to locate the file when the problem occurs, then click that option and provide your exact "/opt/CCSv6/C6748_StarterWare_1_20_03_03/platform/evmC6748/sysdelay.c" path in CCS.

Is is required to go that file to make delays while debugging.

Please attach the screen shot when the error comes.

It may look like this.

The resulting error page looks different for me, but clicking Locate File, I was able to point it to the right source file and then single step delay().

It hangs at line 139.

	while(flagIsrCnt);

I believe this behavior is an interaction between SYS/BIOS and StarterWare.  Most likely, related to timers. 

Has anyone ever tried to run StarterWare USB under Sys/BIOS before?  Is there a tutorial?  A howto?

The StarterWare main() code called DelayTimerSetup(). Did you port that over? That call will mess with the timer interrupts. I am amazed the the StarterWare USB interrupt hasn't tripped you yet. It probably is not SYS/BIOS friendly either.

I am pretty sure others have ported the StarterWare to SYSBIOS. Search on the forums. The lack of a USB driver has always been a shortcoming of SYSBIOS / PSPBIOS. DSPBIOS has BIOSUSB but I think that was something TI would rather it did not exist at all. I gave up using BIOS because the of the lack of USB support.