problem in executing USB examples on Piccollo F2806x devices

Brett,

Many thanks for your support. Yes, I'm using the F2806x Experimenter's Kit Release R1.1. Physically, the External Crystal is missing in the hardware along with the C30 and C31 15 PF capacitors. I'm referening to the \controlSUITE\development_kits\~controlCARDs\CC2806xHWdevPkg\R1_1\F28069controlCARD-SCH[R1.1].pdf document.

Instead of 20 MHz crystal can I give a try with the 16 MHz Crystal? I hope, things work when I place the 20 Mhz crystal along with the C30 and C31 15 PF capacitors. Just curious to know the reason why was 20 MHz crystal for USB examples selected.

Rgds,

Harish

Brett,

Many thanks once again for your support. Well, I was able to include a 20 MHz crystal and was also successful in executing the usb_dev_blk example project.  I also tried single step execution and it was successful. :)

I started the hyper terminal ( with the setting as mentioned in the project) and  tried to view the response sent from the device but nothing was printed on the hyper terminal.

Is there something I'm missing with the settings? Is there any application software where I can check the data on my USB bus for the debugging?

Rgds,

Harish

Harish,

Its good to hear that some one besides myself is playing with USB on the F2806x   :)

I took a look around and I think there are a couple things you should check that might be giving you problems.

What clock speed are you running at?  If you take a look at the SysCtl.c file in MWare you'll find a function called SysCtlClockGet. This gets called by UARTStdioInit (which is in main), to help setup the baud rate for the UART.  This function is hard coded to return 60Mhz which is what the USB examlpes are setup to run at, but if your clocking configuration is different you should adjust this to match you system.

Another thing to check is GPIO setup for the UART.  Do you have the f2806x USB Controlcard? or is this a custom board?  I tested the code on my controlcard with the FTDI usb-serial connection and the UART worked for me.

Trey German

C2000 SW Applications

Trey,

I really appreciate your support. From here on, I can always look forward to your support until my USB is fully functional I guess :D

I'm sorry for the delayed reply. I did check the schematics of the controlcard. I presume a short in the J9 will also help in receiving the data over Hyperterminal but again , I do not have a 20 MHz crystal on the controlcard. As you suggested, the UART pins are used to communicate in usb_dev_bulk example code.

Here are the inputs from my side,

1. I have both, a custom board with F28069 and a f2806x USB controlcard( this experiment kit is powered on by the USB. Let me know if this is what you meant ). I tested the example on the custom board, but realized that GPIO 26 and 27 on my custom board are connected to a Receptical Type B USB connector unlike GPIO 28 and 29 which are connected to the FTDI on the USB docking station. There is no FDTI usb-serial chip on my custom board. So my connection between the board and CPU is via a USB cable.( It will he helpful if there is a example program to test the USB GPIOs and the functionality)

2. I have a 20 MHz external crystal on my custom board and the clock speed for my project is 80 MHz and the LSPCLK is also 80 MHz.

3. Since I'm a newbie to USB, request you to suggest any links in order to understand the USB protocol.

Let me know if I'm missing something wrt to the setup or example code :)

Rgds,

Harish

Harish,

For now lets stick to debug of the F2806x control card because I too have schematics of that board.

You don't necessarily need a 20 Mhz crystal, but clock speeds must be consistent for asynchronous protocols like UART and USB to work.  It sounds like you have USB running successfully, so leave the clock configuration for USB alone.  If you calculate the clock speed that the CPU is running at, and plug it into the driverlib function SysCtlClockGet in the MWare/driverlib/sysctl.c, we can rule out clock configuration for the UART module.

Responses to your numbered statements:

1) I think your are confused about what data is transmitted from where and to what.  The USB dev bulk application demonstrates simple bulk  USB communication, GPIO 26 and 27 are the USB DP and DM pins and should be connected to your computer through a USB cable (just like on the control card and on your custom board).  Basic status information about the example is transmitted out via the chip's SCI peripheral (which for this example is called UART).  On the control card, this is routed through the digital isolators to the FTDI which does USB-Serial conversion and allows you the user to view these status messages by opening the virtual COM port associated with the FTDI device using your favorite terminal program (PuTTy or Hyperterminal).  On your custom board, you probably won't be able to easily see these messages, but if you view the SCI TX pin (GPIO 29) with an oscilloscope you ought to see it toggle as the application runs.  On the controlcard, with everything configured correctly you should definitely see messages from the usb_dev_bulk application in the virtual com port created by the FTDI device on the controlcard.  DO NOT connect J9 on the dock board.  You should be debugging the controlcard using the on board XDS100v2 and NOT the XDS100v1 present on the baseboard.  If you connect USB to the base board the FTDI chip present there will enumerate and potentially drive some of the JTAG and UART signal lines.  This can cause communication to fail.  The only reason the base board should be present in your system is to supply power to the controlcard.

2) Running the core at 80Mhz is fine, just adjust the SysCtlClockGet function to return 80000000 instead of 60000000.  This will should fix any problems related to UART baudrate.

3) USB in a Nutshell!  This is an excellent resource and is actually where I learned about half of what I know about USB.

Look through your setup again with the above in mind and let me know what you come up with.

Trey

Trey,

As you mentioned, I agree that it is much better to work with the development kit and examples :)

We can go one step at a time.

Here are the inputs from my side,

1. I have the MWare project( driverlib) and also tired to rebuild the ccs4( 4.2.3.00004) project by changing the SysCtlClockGet function return value( as mentioned),

unsigned

SysCtlClockGet(void)

{

return 80000000;

//return 60000000;

}

but I received the below compilation errors ,

'Building file: ../systick.c'

'Invoking: Compiler'

"D:/Program Files/Texas Instruments/ccsv4/tools/compiler/c2000/bin/cl2000" --silicon_version=28 -g --include_path="D:/Program Files/Texas Instruments/ccsv4/tools/compiler/c2000/include" --include_path="C:/Texas Instruments/Control Suite/device_support/f2806x/v110/F2806x_common/include" --include_path="C:/Texas Instruments/Control Suite/device_support/f2806x/v110/F2806x_headers/include" --include_path="C:/Texas Instruments/Control Suite/device_support/f2806x/v110/MWare" --diag_warning=225 --large_memory_model --unified_memory --float_support=fpu32 --preproc_with_compile --preproc_dependency="systick.pp" "../systick.c"

'Finished building: ../systick.c'

' '

'Building file: ../uart.c'

'Invoking: Compiler'

"D:/Program Files/Texas Instruments/ccsv4/tools/compiler/c2000/bin/cl2000" --silicon_version=28 -g --include_path="D:/Program Files/Texas Instruments/ccsv4/tools/compiler/c2000/include" --include_path="C:/Texas Instruments/Control Suite/device_support/f2806x/v110/F2806x_common/include" --include_path="C:/Texas Instruments/Control Suite/device_support/f2806x/v110/F2806x_headers/include" --include_path="C:/Texas Instruments/Control Suite/device_support/f2806x/v110/MWare" --diag_warning=225 --large_memory_model --unified_memory --float_support=fpu32 --preproc_with_compile --preproc_dependency="uart.pp" "../uart.c"

>> ../uart.c, line 359: INTERNAL ERROR: no match for MCALL

>> Compilation failure

This may be a serious problem. Please contact customer support with a

description of this problem and a sample of the source files that caused this

INTERNAL ERROR message to appear.

Cannot continue compilation - ABORTING!

gmake: *** [uart.obj] Error 1

'Building file: ../usb.c'

'Invoking: Compiler'

"D:/Program Files/Texas Instruments/ccsv4/tools/compiler/c2000/bin/cl2000" --silicon_version=28 -g --include_path="D:/Program Files/Texas Instruments/ccsv4/tools/compiler/c2000/include" --include_path="C:/Texas Instruments/Control Suite/device_support/f2806x/v110/F2806x_common/include" --include_path="C:/Texas Instruments/Control Suite/device_support/f2806x/v110/F2806x_headers/include" --include_path="C:/Texas Instruments/Control Suite/device_support/f2806x/v110/MWare" --diag_warning=225 --large_memory_model --unified_memory --float_support=fpu32 --preproc_with_compile --preproc_dependency="usb.pp" "../usb.c"

>> ../usb.c, line 232: INTERNAL ERROR: no match for MCALL

This may be a serious problem. Please contact customer support with a

description of this problem and a sample of the source files that caused this

INTERNAL ERROR message to appear.

Cannot continue compilation - ABORTING!

>> Compilation failure

gmake: *** [usb.obj] Error 1

gmake: Target 'all' not remade because of errors.

Build complete for project driverlib

Is there something I'm missing. Do I need to change the clock setting else where?

I guess, until I generate a new diverlib.lib and usblib.lib the project usb_dev_bulk will be not executed successfully.

Let me know, you want me to try any other example code in order to make the USB work.

Once again, Many thanks for your continued support. The study of USB nutshell document is on going :)

Rgds,

Harish

Harish,

I believe I've seen this problem before.  You appear to be doing everything correctly, it is your compiler that is not.

The driver library makes uses of some special compiler features to be able to read and write a (8 bit) byte at a time.  Older versions of the compiler had trouble with this and threw errors.  This has since been fixed in new versions of the compiler.

I'm not sure exactly which version of the compiler this was fixed in, but if you update to the latest and try rebuilding driverlib it should work.

To upgrade you compiler:

• In CCS click on Help -> Software Updates -> Find and Install
• Ensure that "Search for updates of the currently installed features" is select and click finish.

CCS should check for updates and give you the option to install an updated C2000 compiler.  If it doesn't, let me know and we'll dig deeper to get this issue resolved.

Trey

Trey,

Many thanks for your inputs :)

I was able to upgrade my complier to 5.2.11 and was also successful in building the project driverlib.lib and generating the new drverlib.lib.Guess, the old complier only supported the word read and write compared to the new complier.

When I flashed the project and executed (RUN), the system went into a loop.

I was successful in carrying out single step debugging... but the program got looped in the this for loop in the function UARTprintf(char *pcString, ...) in file uartstdio.c

// Find the first non-% character, or the end of the string.

//

for(ulIdx = 0; (pcString[ulIdx] != '%') && (pcString[ulIdx] != '\0');

ulIdx++)

{

}

 Below are my code changes in SysCtrlInit( ) to operate the controller at 80MHz,

//HL - settings to select only Internal Oscillator and to operate at 80MHz

//SysCtrlRegs.CLKCTL.bit.INTOSC2OFF = 0; // Turn on INTOSC2

SysCtrlRegs.CLKCTL.bit.OSCCLKSRC2SEL = 1; // Switch to INTOSC2

SysCtrlRegs.CLKCTL.bit.XCLKINOFF = 1; // Turn off XCLKIN

SysCtrlRegs.CLKCTL.bit.XTALOSCOFF = 1; // Turn off XTALOSC

SysCtrlRegs.CLKCTL.bit.OSCCLKSRCSEL = 1; // Switch to Internal Oscillator 2

SysCtrlRegs.CLKCTL.bit.WDCLKSRCSEL = 1; // Switch Watchdog Clk Src to INTOSC2

//SysCtrlRegs.CLKCTL.bit.INTOSC1OFF = 1; // Turn off INTOSC1

/*

while(SysCtrlRegs.PLLSTS.bit.MCLKSTS);

SysCtrlRegs.PLLSTS.bit.DIVSEL = 0;

SysCtrlRegs.PLLSTS.bit.MCLKOFF = 1;

SysCtrlRegs.PLLCR.bit.DIV = 3;

while(!SysCtrlRegs.PLLSTS.bit.PLLLOCKS);

SysCtrlRegs.PLLSTS.bit.MCLKOFF = 1;

SysCtrlRegs.PLLSTS.bit.DIVSEL = 3;

*/

 while(SysCtrlRegs.PLLSTS.bit.MCLKSTS);

SysCtrlRegs.PLLSTS.bit.DIVSEL = 0;

SysCtrlRegs.PLLSTS.bit.MCLKOFF = 1;

SysCtrlRegs.PLLCR.bit.DIV = 16;

while(!SysCtrlRegs.PLLSTS.bit.PLLLOCKS);

SysCtrlRegs.PLLSTS.bit.MCLKOFF = 1;

SysCtrlRegs.PLLSTS.bit.DIVSEL = 2;

//SysCtrlRegs.PLL2CTL.bit.PLL2CLKSRCSEL = 2;

SysCtrlRegs.PLL2CTL.bit.PLL2CLKSRCSEL = 1; // selected internal oscillator for PLL2

SysCtrlRegs.PLL2CTL.bit.PLL2EN = 1;

SysCtrlRegs.PLL2MULT.bit.PLL2MULT = 12; // need some input

while(!SysCtrlRegs.PLL2STS.bit.PLL2LOCKS);

Pls note, I do not have the external crystal on board.

Rgds,

Harish

Harish,

I think we've found the problem!  USB cannot be clocked from INTOSC2.

There is actually a discrepancy between the datasheet and the technical reference manual.  The clock tree in the TRM isn't complete and lacks the clocking information in regard to USB and the second PLL.  Take a look at page 55 of the datasheet and you'll see that PLL 2 can only be clocked by either: INTOSC1, X1/X2, or XCLKIN.

Try clocking the device with INTOSC1 and I think you should see things start working.  Your PLL multiplier looks correct (10M *12 /2 = 60M).

Sorry about the discrepancy between the TRM and DS.  This will be fixed in the next revision.

Trey

Trey,

As you mentioned, USB PLL cannot be sourced with INTOSC2, I did configure the INTOSC1 for USB, but the system clock was configured to 80MHZ.

I was able to execute the usb example code without any issues (looping ) with the below PLL configurations in SysCtrlInit(),

//Setup Clock

//10MHz ->PLL->60MHz->C28

// ->PLL2->120MHz->USB

SysCtrlRegs.CLKCTL.bit.INTOSC1OFF = 0;

SysCtrlRegs.CLKCTL.bit.OSCCLKSRCSEL=0; // Clk Src = INTOSC1

SysCtrlRegs.CLKCTL.bit.XCLKINOFF=1; // Turn off XCLKIN

SysCtrlRegs.CLKCTL.bit.XTALOSCOFF=1; // Turn off XTALOSC

SysCtrlRegs.CLKCTL.bit.INTOSC2OFF=1; // Turn off INTOSC2

SysCtrlRegs.CLKCTL.bit.WDCLKSRCSEL = 1; // Switch Watchdog Clk Src to INTOSC2

while(SysCtrlRegs.PLLSTS.bit.MCLKSTS);

SysCtrlRegs.PLLSTS.bit.DIVSEL = 0;

SysCtrlRegs.PLLSTS.bit.MCLKOFF = 1;

SysCtrlRegs.PLLCR.bit.DIV = 3;

while(!SysCtrlRegs.PLLSTS.bit.PLLLOCKS);

SysCtrlRegs.PLLSTS.bit.MCLKOFF = 1;

SysCtrlRegs.PLL2CTL.bit.PLL2CLKSRCSEL = 1;

SysCtrlRegs.PLL2CTL.bit.PLL2EN = 1;

SysCtrlRegs.PLL2MULT.bit.PLL2MULT = 12;

while(!SysCtrlRegs.PLL2STS.bit.PLL2LOCKS);

And changes in sysctl.c are as below,

unsigned

SysCtlClockGet(void)

{

//return 80000000;

return 60000000;

}

Below are the couple of queries from myside,

1. why 120 MHz clock selected for USB? What is the significance. When I programmed the device for 80MHz, the usb experiment was in a infinite loop.

2. How can I check the output of this example. I had opened the HyperTerminal (COM1 - settings -> 8 -N -1). Nothing appeared on the screen.

Can I probe any particular pins to check the output.

Pls note: the only connection I have with the kit and CPU is a USB cable. Let me know if I have to include any additional connections.

Also, I had created the TestCertificate.cer using the WinDDK application.

Awaiting your inputs.

Kind Regards,

Harish

Harish,

Good to hear that you got it working!

1) USB is an asynchronous communications peripheral.  Because of this USB requires a low jitter clock at a defined speed (60MHz).  There is a fixed divide by 2 after PLL2 so we set up PLL2 to generate 120MHz.

2) You will only be able to see the serial output of the example if you are somehow connected to the device's SCI peripheral and the baud rate/clocking settings are correct.  If you are on a custom board, I suspect that your problem is that you simply aren't physically connected to the SCI.  If you are trying this on a control card you ought to be able to use the virtual COM port present in the XDS100 to connect to the SCI peripheral.  Make sure that your SysCtlClockGet function returns the speed of the main system clock (not USB).  This function is used when calculating the baudrate setting, and if it is incorrect serial communications will not work.

Trey

Trey,

I'm testing the example on the development kit alone cos it is easy for you to resolve the issues as mentioned earlier.

The Virtual Com port is bit confusing. What do you refer to when you mention about Virtual com port. Is it COM1 port or COM2 ..etc, which I can check/configure via HyperTerminal.

The port number which I have passed is 0. so, this indicates that I need to select COM1 in the Hyperterminal.

UARTStdioInit(0); // port 0--> COM1 in my CPU

Also, the UARTprintf() function should print the below message some where,

UARTprintf("\033[2JBulk device application\n");

But, I'm not able to see the printed message on my Hyperterminal.

Would love to see something printing on the screen..

Let me know, if something is missing in the configurations.

Many thanks once again for your support :)

Kind Regards,

Harish

Trey,

I'm really excited to inform you that things worked as expected.

I apologies for the delay in the response.

Let me know what would be best to try out. Which experiment

Many thanks once again for your support :)

Kind Regards,

Harish

Good to hear Harish!

Any of the examples are good to play around with.  It just depends on what you want to do with USB.  Find an application that is similar to what you want to accomplish and build upon that.

Trey

Trey,

I forgot to mention few things..

The message from the example was displayed, but not using the 115200 baudrate.
I was able to view the print messages using 57600 baudrate.

Also, I was unable to enter any data since there was a mismatch in baudrate.  Let me know if I need to modify the code.

The examples provided in control suite V110 works with the UART ports using the FTDI ASIC.

Are there any examples where I can directly use the USB ports of the Piccolo controller.

Kind Regards,
Harish

Harish,

Hmmm, either the crystal on your control card is 10MHz (mine is 20) or you might be using the internal oscillator (which also runs at 10Mhz). 

If you are able to see data coming from the UART, you ought to be able to transmit data back.  There is no mismatch in baudrate if you see the text from the piccolo.

For the above two observations which example are you using?

Yes, the USB examples for the F2806x have already been released and are in the examples folder for the F2806x.  ControlCARDs with USB ports for the F2806x will be available soon.

Trey

Trey,

You are absolutely correct. I'm using the internal oscillator 1 for the usb_dev_bulk example.
Reason: I do not have any external crystal on Control Card. Internal oscillators are 10 MHz..

If I trying to enter any data via the Hyper terminal, the characters are not appearing as expected.
For example: 'A' would appear as different symbol.

Let me know, if there is any work around for the same.

Many thanks for the support . Will wait for the new USB module Control Cards :)

Kind Regards,
Harish

Where were you able to get a F28069U USB controlCard?  I've been looking for one but heard they weren't available for another month.

Thanks!

Cyril

Cyril,

I have not yet ordered any new F28069U USB controlCard.

Thanks for the info. I will check on the same and update you accordingly.

Rgds,
Harish

Cyril and Harish,

F28069U controlCards are almost here!  I believe they are currently being manufactured and packaged.  Keep a look out for them in the TI eStore soon!

Trey

Hi @all,

I'd like to thank Trey and Harish for this hole discussion because it helped me a lot to setup the UART for the Piccolo controlStick. This was really helpful.

Thanks....