MSP430F55XX USB enumeration fails on reconnect

Were you using breakpoints when you were seeing the issue with USB disconnect/connect? What happens when you dont' use any break-points or single stepping while executing the code, do you see the same behavior?

Also, you mentioned that the "first time enumeration" happened fine everytime. Was the USB cable connected to the target board (MSP-TS430PN80USB) initially before running the code or was it connected only after the code execution was started?

Which revision of the MSp430F5529 device are you using (RevA or RevB)?

Regards,

Bhargavi

I have not had these problems so far. I just tested it out on Example 6 and it seems to be working for disconnect/reconnect. I am using the IAR version, so I cannot speak for the CCS version.

One thing to remember when using the CDC API is that you need to be careful about the order of operations between your code and hyperterminal. This might be your problem, so I'll do a quick example. Let's assume you are debugging Example 6.

1. With your device reset, open up Device Manager. Under the Ports pulldown you shouldn't see you device in the list yet since its not running.

2. With all breakpoints removed, hit go on the debugger. If the USB cable is plugged in you should see your device added in the Ports pulldown list. If the cable is not plugged in, this will happen when you plug in the cable.

3. Open hyperterminal and select the appropriate COM port. Baudrate, and flow settings are not used. It should connect to the target and you should see "Press any key". The cursor will move to let you know the communication is continuous.

4. In hyperterminal, disconnect. Now remove the USB cable. Your device will disappear from the Device Manager ports list.

5. Plug the USB cable back in. You device will appear again in the Device Manger ports list.

6. In hyperterminal, connect again. The cursor will move again. The text may also appear garbled since it will write "Press any key" from wherever the cursor stopped last.

If you follow this order of operations everything should work. The key is to remember to disconnect within hyperterminal before removing the USB cable, and to connect within hyperterminal after Device manager finds the device. Otherwise Windows And/Or hyperterminal gets stuck and cannot find the device.

As mentioned by others, also beware breakpoints. The USB protocol has timing requirements which will not be met if the CPU is not clocking the USB module.

darkwzrd

Bhargavi said:

Were you using breakpoints when you were seeing the issue with USB disconnect/connect? What happens when you dont' use any break-points or single stepping while executing the code, do you see the same behavior?

The behavior is also seen when running stand-alone (FET is only used for power-supply), so CCS is not running. With CCS opened and no breakpoints set, the bahavior is the same.

Bhargavi said:

Also, you mentioned that the "first time enumeration" happened fine everytime. Was the USB cable connected to the target board (MSP-TS430PN80USB) initially before running the code or was it connected only after the code execution was started?

I just checked and observed the following (slightly different than I mentioned in my first post):

- Apply power to the target board (connect FET USB cable) first and then connect the USB cable afterwards->enumeration fails  the first time too. Disconnect/connect the USB cable afterwards has the same behavior (enumeration fails).
- Connect USB cable first and then apply power to the board (connect FET USB cable)-> enumeration succeeds. Disconnect/connect USB cable afterwards->enumeration fails. Device appears as Unknown Device in the Universal Serial Bus Controllers node in the device manager.

Bhargavi said:

Which revision of the MSp430F5529 device are you using (RevA or RevB)?

I'm using Revision A.

Thanks for your help and best regards,

Norbert

Hi Rosty,

Thanks for your answer.

I see a bus error condition arriving in the NMI interrupt routine indeed. Unfortunately, we currently don't have 47pF capacitors on stock here so I'll have to wait till after the weekend to test this. Thanks so far.

Regards,

Norbert

Hi Rosty,

We are using TI's MSP-TS430PN80USB rev 1.2 . We checked the capacitors around XT2 and they are 47pF, so that seems to be OK.

However, we do get the bus error in the NMI ISR. Do you have any other suggestions how we can eliminate the problem?

Thanks for your help.

Regards,

Norbert

Hi Norbert,

the NMI bus error may occur:

- the CPU access the USB shared memory and the USB memory is not ready (the PLL is stopped or running not properly started)

- the USB machine access USB memory but it is used by CPU (e.g. when CPU is too slow, MCLCK is < 1.5MHz)

I have two questions:

1. Do you use examples 'as is'?

2. Could you please step out from NMI ISR handler (pls use single stepping in asm mode) in order to see which place in code initiate the Bus Error?

Thank you,
Rosty

Hi Rosty,

Rostyslav Stolyar said:

1. Do you use examples 'as is'?

Yes and No. I have made no changes to source code whatsoever. However, because the examples are made for CCS 4.1 (I guess), I had to made some changes to include paths and device include files because I'm still using CCS 4.0.2

Rostyslav Stolyar said:

2. Could you please step out from NMI ISR handler (pls use single stepping in asm mode) in order to see which place in code initiate the Bus Error?

See picture below for the return position after the NMI (line 401 in usb.c)

Thanks and best regards,

Norbert

Hi Norbert,

I tried to re-create what you are seeing but couldnt. I ran one of the CDC code examples and the device enumerated fine as long as I didnt use any breakpoints in VbusOn handler or USB_ConnectionState function. However, I am using the RevB device. Is it possible you sample the RevB devices and check if you see the same issue. RevB devices are the latest experimental silicon and RevA devices are the earlier ones. I would suggest you sample a RevB device and check if you are seeing the same issue or else could you try using the extra code (see below) in the USB_enable() function to see if the issue is related to the revisions?

Essentially we are turning ON XT1 oscillator briefly before the USB PLL is initialized and the XT1 oscillator can be turned off once the PLL is initialized.

#ifdef __EXTRA_CODE__
    P5SEL |= 0x30;
    UCSCTL6 &= ~XT1OFF; // enable XT1 even if not used
#endif
//… Perform PLL initialization …..//
// …Wait for PLL to settle …..//
#ifdef __EXTRA_CODE__
    UCSCTL6 |= XT1OFF; //
    UCSCTL7 &= ~((DCOFFG+XT1LFOFFG+XT1HFOFFG+XT2OFFG) | 0x04); // Clear OSC flaut Flags
    SFRIFG1 &= ~OFIFG; // Clear OFIFG fault flag
#endif

Regards,

Bhargavi

I realize this is an old thread but I'm seeing this exact same problem. 

I don't believe the verified answer to this thread is applicable for my situation.  I'm using the MSP-EXP430F5529 Experimenter Board Rev 2.1.  The REV of the 5529 is E--so my hardware is certainly much newer.

I believe the caps associated with XT2 are in place but I can't be 100% for sure as the latest documentation, slau330 REV A, references an older board rev for the MSP-EXP430F5529 Experimenter Board--REV 2.0.  (There are no missing components around Q2, however there are unpopulated parts next to Q1--the LFXTCLK crystal.)

The Demo code will sometimes work but not always.  My code, built with the MSP430 USB Descriptor Tool, will never enumerate the USB device in this situation.  My code will always get hung up in the USB_reset function assigning settings for IEPx and OEPx.

Any help would be appreciated.