USB Developer Kit example runs on F5527 but not on F6638. Ideas?

hmm, 5527 is a 64 or 80 pin device and the 6638 is a 100 pin.
There are differences in the pinout, so is XT1 connected to Pin12/13 of the 5527 (and multiplexed with P5.4/5.5) but to pin 13/14 of the 6638. Similar for XT2. There might be a problem with your clock (and without a proper clock, the USB part won't enumerate for sure)

Also, there of course is a chance that the header files have a bug - you can manually go through the headers and compare the register addresses with the datasheet. It happened before.

The USB Developer Kit accounts for the pinout differences in the two devices - the 5527 uses P5 and the 5636 and 6638 use P7 for XT2. I've dug through the code, can see the highlighted differences, and have compared them with the datasheets.

The Init_clock() routine in main.c initializes XT2. It gets the target frequency (USB_MCLK_FREQ) from the descriptors.h created by MSP430_USB_Descriptor_Tool.exe then calls one of the F5xx_F6xx_Core_Lib common routines:

Init_FLL_Settle(USB_MCLK_FREQ / 1000, USB_MCLK_FREQ / 32768);   //Start the FLL, at the freq USB_MCLK_FREQ
XT2_Start(XT2DRIVE_0);                                          //Start the "USB crystal"

Execution always gets through XT2_Start without problem (I've tried several freqs; one note somewhere said 4MHz or 8 MHz were the optimal but I don't recall why). Several other posts reported XT2 hangs due to an errata supposedly fixed on my Rev D 5638 and Rev E 5529. I believe it because XT2_Start doesn't hang (there's a one line loop that checks for OSC fault).

I'll double check the header files, and double check the actual freq via scope again (during these side by side tests the example programs were used without any mods at all). It is suspicious that the USB Developers Kit uses the 5527 as the primary target and that's the MCU that enumerates correctly. I've checked the value of USB_MCLK_FREQ via breakpoint and it's correct when Init_FLL_Settle() is called. One would think the F5xx_F6xx_Core_Lib common routines have been checked pretty well so I doubt there's a bug there. In the meantime I'm using a UART workaround to keep things moving, it works but but it's frustrating.

A positive is that I understand TI's USB code pretty well. On another positive note, TI's USB Developer's Pkg user manual is exceptionally well written.

I just wish the TI engineers could recreate my 5527 (their chip/board/software) versus my 5636 or 6638 setup and tell me if I'm right or crazy.

Hi Doug,

My guess is that your Init_FLL_Settle is setup incorrectly for using the 4MHz XT2 xtal...

Init_FLL_Settle(USB_MCLK_FREQ / 1000, USB_MCLK_FREQ / 32768);   //Start the FLL, at the freq USB_MCLK_FREQ

I'm prototyping on the MSP-TS430PZ100USB board and have had no problems with the Rev D 5638 parts (but had to install the 32768Hz xtal for the Rev A parts that came with the board). I'm running the main clock at 20MHz, so my Init_Clock setup is as follows...

//Configure the XT2 pins and enable the XT2 oscillator
P5SEL |= 0x0C;
UCSCTL6 &= ~XT2OFF;

//Set FLL to use XT2 divided by 16 as the reference freq (250KHz ref freq)
UCSCTL3 = (UCSCTL3 & ~(SELREF_7 + FLLREFDIV_7)) | (SELREF__XT2CLK + FLLREFDIV__16);

//Set the auxiliary clock (ACLK) to use the XT2 oscillator
//Don't use the DCO output for ACLK because of the jitter induced by the spread spectrum modulation (MOD)
//Using XT2 for ACLK will ensure that it's jitter free
//ACLK will be used with timer A to produce the 5ms interrupt timebase
UCSCTL4 = (UCSCTL4 & ~(SELA_7)) | (SELA__XT2CLK);

//Setup and initialize the FLL
//Init_FLL(fsystem, ratio) where 'fsystem' is the desired DCO freq (USB_MCLK_FREQ)
//The 'ratio' is USB_MCLK_FREQ/FLLREF where FLLREF equals XT2/FLLREFDIV
//The output freq is equal to XT2/FLLREFDIV times the 'ratio'
Init_FLL_Settle(USB_MCLK_FREQ/1000, USB_MCLK_FREQ/250000);

Note that the reference frequency for the FLL is setup using UCSCTL3.

The 'ratio' for Init_FLL_Settle is USB_MCLK_FREQ divided by the reference frequency (250KHz as set by UCSCTL3 in my application).

Your 'ratio' of USB_MCLK_FREQ / 32768 looks suspicious for using the 4MHz XT2 xtal.

Hope this helps...

Steve

Steve,

Thanks, I can't try it for a few days but will do so.It looks promising.I thought there would be time to try it this afternoon, but nothing happens as fast as expected.

BTW, the ratio "USB_MCLK_FREQ / 32768" is from the TI example code.

Thanks again,

Doug

Hi Doug,

The USB API and examples were designed to be run out of the box on F552x/551x, F550x, and F663x/563x FET target boards, using either IAR or CCS (as long as you select the correct device in the project options).  As long as you haven't replaced the crystal with another frequency, the examples ought to have worked. 

I assume you didn't make any changes to the FET target board hardware, but please confirm. 

Differences in terminal apps can mess with the CDC examples -- this might have caused the other minor problem you mentioned.  But your device should at least enumerate. 

Can you give a little more information about what you're seeing?  All I see above is that it's making it past the clock initialization code, but then "isn't enumerating".  Do you see any activity at all on your Windows host?  (like a bubble at the system tray, or an error showing up in the Device Manager) 

When you halt MSP430 execution and step through it, what state is returned by USB_connectionState()?

You might want to probe PUR to ensure that it got pulled high -- this is how the device tells the host the device is 'out there'.  For what it's worth, you might also then probe D+/D- and see if they're wiggling after insertion, and for how long before it gives up.  (I assume you don't have a bus analyzer.)

You might try outputting XT2 to a pin (i.e., via SMCLK) to ensure it's operating properly.  I wouldn't expect it to make it past the clock initialization code if it wasn't, but worth confirming.  (Let us know if you need some direction on this.) 

Regards,
Keith

Keith,

Thanks for responding. I'll answer in sequence.

Para 2: We did not make any changes to the development board, including the XT2 XTAL.

Para 4: We do not see any 'new hardware found' icon or any hidden loading of a device driver. I used USB Trace and several different USB hosts and did not see any USB packets request device configuration. I don't have a hardware packet analyzer. However, if the USB code is left halted at a breakpoint then connected to the host we get an 'illegal hardware found' message box and can see an 'X' (or whatever symbol) in the System Devices control panel.

Para 5, 6: When I was debugging I added code to track USB states, interrupts and PUR. When I last tried Example 4 I used it out of the box to make sure I didn't screw something up. From the debug version:

     When the USB is disconnected, the loop reliably goes to sleep in
     state  ST_USB_DISCONNECTED

     The following shows events for one connect/disconnect cycle beginning
     in state ST_USB_DISCONNECTED:

    --- Connect cable

     iUsbInterruptHandler(VOID) called, with interrupt USBVECINT_PWR_VBUSOn

     USB_connect () called, pulling PUR high

     enter state ST_ENUM_IN_PROGRESS:            // 0x82

     --- hangs here
     --- Disconnect cable

      iUsbInterruptHandler(VOID) called, with interrupt USBVECINT_PWR_VBUSOff:

     enter state ST_USB_DISCONNECTED:

     Note that PUR never seems to be pulled low. It appears to be pulled low by
     usb_disconnect() in usb.c, but I didn't find any routine calling usb_disconnect()
     in the example. Also note that sometimes after state ST_ENUM_IN_PROGRESS
     is entered, a suspend event occurred (without a USB interrupt) and the code goes
     into state ST_NOENUM_SUSPENDED.

Para 7. We verified via scope and DVM that PUR was pulled to 3.36 V with 0.36V ripple.

Para 8. I output XT2 to P1.0 and did 2 calcs via scope and measured 4.0 and 4.16 MHz using the following snippet (I don't know if TI or I added this):

      P1SEL |= BIT0;    // ACLK out P1.0, pin 34 on F5636 and F6638
      P1DIR |= BIT0;
      SELECT_ACLK(SELA__XT2CLK);

Thanks,

Doug

Edit: This morning (1/11/12) I tried the debug version of the code on the MSP-EXP430F5529 USB Experimenters board and it enumerated using the COM driver built with the MSP430_USB_Descriptor_Tool.exe provided with the USB Developers Package. I can see our Manufacturer name in the Device Manager Properties for COM ports.

When I unplugged the USB cable the COM port disappeared as it should.

When I plugged the USB cable back in the device again enumerated with our virtual COM port driver.

However, the code would still not run on on the 6638.

So, again, char for char identical software will enumerate on a 5529 (MSP-EXP430F5529 USB Experimenters board ) but not the 6638 with the MSP-TS430PZ100USB development board.

Doug,

Can you give more detail of what you see in USBTrace?  Your exact words ("did not see any USB packets request device configuration") suggest that the host is ignoring the F663x, even though PUR is high, which would suggest some kind of strange host problem -- but you saw this happen on multiple hosts.  I'm wondering if in fact the host is trying to talk to us, and we're not responding? 

As a side note -- there's a jumper between VBAT and VCC -- is this jumper being applied?

This is a long shot, but have you tried a different USB cable? 

Regards,
Keith

Keith,

Keith Quiring said:

Can you give more detail of what you see in USBTrace?  Your exact words ("did not see any USB packets request device configuration") suggest that the host is ignoring the F663x, even though PUR is high, which would suggest some kind of strange host problem -- but you saw this happen on multiple hosts.  I'm wondering if in fact the host is trying to talk to us, and we're not responding? 

Not responding would be my guess. Attached is a USBlyzer trace below. It's a .txt file but is really a .csv file as I couldn't upload a .csv file. The MSP430 USB development board is the only thing plugged into this Root Hub. This type of trace is triggered when the USB cable is inserted.

Note that I'm trapping all UNMI_ISR() interrupts, all USB state transitions and all iUsbInterruptHandler() interrupts and the only ones occurring are listed above.

The PCs I've tried have never had any problem enumerating any USB devices. And if I run the exact same code on the 5529 USB experimenters board it enumerates with the host PC.

Keith Quiring said:

As a side note -- there's a jumper between VBAT and VCC -- is this jumper being applied?

There is a jumper between pins 1 and 2 of JP11 (DVCC and VBAT).

Also, there is a jumper from pins 2 to 3 on JP3. A pumper on JP1, and jumpers on JP5-JP10, all between pins 2 and 3. There is a jumper on JP2.

To my knowledge we didn't change any jumpers - want to make things work first.

Keith Quiring said:

This is a long shot, but have you tried a different USB cable? 

Yes. I swapped the USB cables between the MSP-FET430UIF and the MSP-TS430PZ100USB boards and got identical results (i.e., successful code download/debug but fail to enumerate). So, I'm 99+% sure the cables are OK.

The following file is really a .csv file.

8540.USBlyzer_Output.txt

Thanks,

Doug

This morning I ran the identical project as described in my prior two posts on the 5529. All I did was change the target MCU to the 5529, changed P9OUT to P8OUT (no P9 on the 5529), plugged the FET and USB cable into the MSP-EXP430F5529 board. It enumerated mostly OK. I had to point it to the right .inf file but I can live with that for now.

The USBlyzer capture file showing the enumeration sequence is here (once again, it's really a .csv file) 7827.USBlyzer_running_on_5529_enumerates.txt

There must be something wrong with the 6638/ MSP-TS430PZ100USB combination. The identical software running on a 5529/MSP-EXP430F5529 combination in the same CSS workspace with the same host PC enumerates.

Thanks,

Doug