This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430F5510: XT2 frequency shift when USB PLL is active

Part Number: MSP430F5510
Other Parts Discussed in Thread: MSP-FET

I've been trying to debug issues with USB on the MSP430F5510; the controller never sets SETUPIFG on a SETUP packet.  I know the host sends them.  I've scratched my head trying to figure out the issue here; it's not intermittent, but consistent.  I've never seen a SETUP interrupt.  Everything else works fine.  I don't have a USB Protocol Analyzer unfortunately...  I get no PLL interrupts unless I short the XT2 crystal briefly with a resistor, to verify they happen.  They do happen!  All at once when I abuse the clock.

The crystal is 12MHz, and I'm not using the UCS FLL.  I run the DCO for some of the device errata suggesting the USB PLL can fail to start up otherwise, but it's not used during operation - MCLK is XT2 1:1, SMCLK and ACLK are divided by 4.

So I decided to check the crystal frequency.  First verified it oscillates with a scope (with a LeCroy ZS1000 active probe, 0.9pF 1M).  One crystal terminal is clean, the other a little noisy looking, but not terribly so.  I didn't take note, but I assume it's XT2IN that's noisier due to its higher impedance.

Next, I routed ACLK to P1.0 (with ACLK dividing the XT2CLK by 4, for 3MHz) and probed it with a counter (Agilent 53131A).  It measures 2.999966MHz, which is a deviation of ~11ppm.

But when I plug in the USB connector the frequency drops to 2.996200MHz, which is off by 0.12%!  This exceeds the USB 0.1% clock spec.  When the host gives up enumerating and suspends the device (at wihich point I shut off the USB PLL) ACLK climbs back up to the same as when not plugged in.  The ACLK is stable at the weird frequency; it's not skipping around like one would assume with noise/jitter.

What is the likely root cause here?

Could this clock shift cause SETUP to always fail?  It's only 2.0 Full Speed...  I'd expect if it were so close to the limit of the spec it would intermittent and not consistent.  I NEVER see a SETUPIFG.

It doesn't SEEM to be caused by noise over VBus.  (I don't have a ferrite bead on it, but it does a Schottky.)

The USB cable shield is unattached.

  • I just tried one of the USB demos (H8_Keyboard), and it works flawlessly - so it's not a hardware problem. So I guess I'm stuck trying to figure out why the UBM simply refuses to accept a SETUP...
  • Hello Jan,

    My first suggestion was for you to try one of the examples already made to make sure it works. The next step is to see what setup differences you have between the example and your orignal code to narrow down the issue. Also the MSP430 must be a VCORE level 2 for the USB module to function properly. Did you change the VCORE level appropriately in your original code?
  • I do set Vcore.  I just also tried using the code form the demos (pmm.c) instead of adopting the code on p108 of slau208o (F5xx and F6xx Family Guide), including the stepping.  It succeeds stepping up to either level 2 or 3, but no dice with the USB module...

  • The only thing I can see at this point is the demo enables the FLL which I don't current use...
  • Enabled the DCO to run at 24MHz with the FLL, verified it with a counter via ACLK on P1.0. Now I'm running MCLK off the DCO at 24MHz and ACLK/SMCLK at 3MHz off XT2 directly. Vcore level 3. Still not seeing setup packets... :(
  • I never used DCO with USB, because I need performance and precision. Boards are running only (and power supplied) by PC connection, so consumption is more or less irrelevant.. Never found (till today) MSP430F5510 sample that was not able to work (USB) at 24 MHz MCLK / SMCLK sourced from 24 MHz XT2 at default Vcore level (zero) and 2.0V VCC on room temperature.

    MSP430F5510 also can run USB module directly by 48 MHz XT2 and bypassed (disabled) PLL, but not on low voltage (if I remember right, must be higher than 2.5V). Again, on room temperature.

    (For me) it is impossible to debug USB by breakpoint / debugger. I used high rate UART (1 Mbps) logging for this. Made my own USB stack from zero, following TI original open source USB dev pack.

    Try to start from TI open source working example, similar to your target, and make modification in small steps.

  • What do you mean by "impossible to debug by breakpoint"? It should be perfectly possible to set a HW breakpoiont in an ISR to make sure an interrupt happens.  Once this is confirmed, you reset and start over.  If the MSP-FET prevents this either by interfering with interrupt logic or causing the IFG to be cleared, then it's completely unusable.

  • Hello Jan,

    Glad to see that the example code works well. Did you enable the setup IFG int he demo and saw those packets as well?
  • Hmm, maybe I should, just to verify that it works.

    I just received a LeCroy Mercury T2 USB Protocol Analyzer, and I could immediately see the USB transceiver never sends anything at all, almost as if FEN or PUSEL weren't set.   The host keeps trying and goes through SE0->SETUP IN->RESET, then tries again.  It starts with RESET and SOF on physical connect.  The UBM never says squat, and in fact triggers suspend since it apparently believes the bus is inactive for 3ms.  The Analyzer trace shows it's not.  So either the transceiver remains disabled, or the PLL is locked to the wrong frequency, or gated off from the transceiver.  This is without the MSP-FET connected or any debugging going on.

    I also see that the demo runs the FLL off REFO at 32768Hz to discipline the DCO, while I don't use REFO at all.  I wonder if REFO has to be active?

  • Tried running the FLL off REFOCLK; makes no difference  the UBM is still silent.

    Correction on SE0, that doesn't happen until later...  Here's the first 21 packets.  All H->S.

    Packet#
    _______|_______________________________________________________________________
    Packet(1) Dir Reset(  3.883 us) Idle(34.000 ns) Time Stamp(31 . 938 658 966) 
    _______|_______________________________________________________________________
    Packet(2) Dir F(S) Sync(_0000001) IN(0x96) ADDR(5) ENDP(3) CRC5(0x12) 
    _______| EOP(266.660 ns) Pkt Len(36 Bits (5 Bytes)) Duration(  2.933 us) 
    _______| Idle(  1.315 us) Time Stamp(31 . 938 663 550) 
    _______|_______________________________________________________________________
    Packet(3) Dir Reset(  3.700 us) Idle(33.330 ns) Time Stamp(31 . 938 667 132) 
    _______|_______________________________________________________________________
    Packet(4) Dir F(S) Sync(00000001) IN(0x96) ADDR(5) ENDP(3) CRC5(0x12) 
    _______| EOP(266.660 ns) Pkt Len(36 Bits (5 Bytes)) Duration(  2.933 us) 
    _______| Idle(  1.233 us) Time Stamp(31 . 938 671 532) 
    _______|_______________________________________________________________________
    Packet(5) Dir Reset(  5.450 us) Idle(33.340 ns) Time Stamp(31 . 938 675 032) 
    _______|_______________________________________________________________________
    Packet(6) Dir F(S) Sync(00000001) IN(0x96) ADDR(5) ENDP(3) CRC5(0x12) 
    _______| EOP(266.660 ns) Pkt Len(36 Bits (5 Bytes)) Duration(  2.933 us) 
    _______| Idle(  1.483 us) Time Stamp(31 . 938 681 182) 
    _______|_______________________________________________________________________
    Packet(7) Dir Reset(  7.334 us) Idle(33.340 ns) Time Stamp(31 . 938 684 932) 
    _______|_______________________________________________________________________
    Packet(8) Dir F(S) Sync(_0000001) IN(0x96) ADDR(5) ENDP(3) CRC5(0x12) 
    _______| EOP(266.660 ns) Pkt Len(36 Bits (5 Bytes)) Duration(  2.933 us) 
    _______| Idle(  1.249 us) Time Stamp(31 . 938 692 966) 
    _______|_______________________________________________________________________
    Packet(9) Dir Reset(  4.233 us) Idle(34.000 ns) Time Stamp(31 . 938 696 482) 
    _______|_______________________________________________________________________
    Packet(10) Dir F(S) Sync(_0000001) IN(0x96) ADDR(5) ENDP(3) CRC5(0x12) 
    _______| EOP(266.660 ns) Pkt Len(36 Bits (5 Bytes)) Duration(  2.933 us) 
    _______| Idle(  1.199 us) Time Stamp(31 . 938 701 416) 
    _______|_______________________________________________________________________
    Packet(11) Dir Reset(  4.268 us) Idle(33.340 ns) Time Stamp(31 . 938 704 882) 
    _______|_______________________________________________________________________
    Packet(12) Dir F(S) Sync(_0000001) IN(0x96) ADDR(5) ENDP(3) CRC5(0x12) 
    _______| EOP(266.660 ns) Pkt Len(36 Bits (5 Bytes)) Duration(  2.933 us) 
    _______| Idle(  1.249 us) Time Stamp(31 . 938 709 850) 
    _______|_______________________________________________________________________
    Packet(13) Dir Reset(  4.233 us) Idle(34.000 ns) Time Stamp(31 . 938 713 366) 
    _______|_______________________________________________________________________
    Packet(14) Dir F(S) Sync(_0000001) IN(0x96) ADDR(5) ENDP(3) CRC5(0x12) 
    _______| EOP(266.660 ns) Pkt Len(36 Bits (5 Bytes)) Duration(  2.933 us) 
    _______| Idle(  1.265 us) Time Stamp(31 . 938 718 300) 
    _______|_______________________________________________________________________
    Packet(15) Dir Reset( 69.868 us) Idle(33.330 ns) Time Stamp(31 . 938 721 832) 
    _______|_______________________________________________________________________
    Packet(16) Dir F(S) Sync(_0000001) SOF(0xA5) Frame #(1652) CRC5(0x17) 
    _______| EOP(250.000 ns) Pkt Len(35 Bits (5 Bytes)) Duration(  2.917 us) 
    _______| Idle(  1.250 us) Time Stamp(31 . 938 792 400) 
    _______|_______________________________________________________________________
    Packet(17) Dir SE0(166.667 ns) Idle(32.670 ns) Time Stamp(31 . 938 795 900) 
    _______|_______________________________________________________________________
    Packet(18) Dir F(S) Sync(_0000001) IN(0x96) ADDR(5) ENDP(1) CRC5(0x06) 
    _______| EOP(250.000 ns) Pkt Len(35 Bits (5 Bytes)) Duration(  2.917 us) 
    _______| Idle(  1.334 us) Time Stamp(31 . 938 796 766) 
    _______|_______________________________________________________________________
    Packet(19) Dir SE0(950.000 ns) Idle(33.330 ns) Time Stamp(31 . 938 800 350) 
    _______|_______________________________________________________________________
    Packet(20) Dir F(S) Sync(00000001) IN(0x96) ADDR(5) ENDP(3) CRC5(0x12) 
    _______| EOP(250.000 ns) Pkt Len(35 Bits (5 Bytes)) Duration(  2.917 us) 
    _______| Idle(  1.282 us) Time Stamp(31 . 938 802 000) 
    _______|_______________________________________________________________________
    Packet(21) Dir Reset(  4.100 us) Idle(33.340 ns) Time Stamp(31 . 938 805 532) 
    _______|_______________________________________________________________________
    

  • Setting breakpoints in the demo code's UBM ISR (include the SETUPIFG conditional) works fine. It stops there every time I connect the cable to start enumeration. The wait states seem to have no impact.
  • Hi Jan,
    Is it possbile to get some clarification? I understand that you ran the H8_Keyboard example successfully, however having problems when you run your application.

    Are you using the same USB libary code base (the files found in USB_API) that came with the H8_Keyboard example or have you changed the existing code? If so what changes did you make?

    Is your application following the USB and PMM setup procedure as listed in the H8_Keyboard example? In this order:
    PMM_setVCore(), initPorts, initClocks, initButtons, Keyboard_init, USB_setup()?

    If your application is a Keyboard is it possbile to use the H8_Keyboard example project as is but replace the items in the while() loop in main.c file with the contents of your application and see if you get the SETUP packets?

    Regards,
    Arthi
  • I'm not using any TI code at all.  This is a code base ported over from NXP ARM Cortex-M that started its life in the ARM7TDMI era, so needs to hook into a specific task scheduling and memory management model.  The much smaller resources, lack of ethernet, effective lack of dynamic memory (although dlmalloc could be used I suppose), and so on is fine for many trivial applications.  It still permits leveraging existing known reliable code.  Pretty much everything else other than this stupid USB interface works, including deadline scheduling, rendering to an LCD TFT panel - except for touch input and deep sleep (LPM4) which I haven't implemented yet.  Both of those and simple and neither worries me the way the USB interface does.   The only TI code I use is msp430f5510.h and even that will probably get replace eventually (I hate how it uses #define's rather than enums, which means it can't be contained in a namespace and it's real easy to get tripped up over some of the names, like NAK.  Fortunately since I use enums this just results in compile error, not totally broken code, but such a huge list of #define's is pretty disconcerting.  Besides I prefer to use packed structs to describe devices, with accessors for anything nontrivial, but this only works when devices are laid out contiguous in memory; using the TI header files makes it easy to support multiple processor families).

    When checking the USB device registers in the TI setup interrupt handler they're all configured exactly identically to what my code produces prior to expecting to see a SETUP, with one exception - FEN isn't set in the TI code.  I tried not clearing it to match, with no success.  Bit for bit, they configure the USB module identically - but then this hardware isn't idempotent and has a LOT of hidden variables and logic.

    I can see USBFN changing whenever I pause my code, so I know it's picking up the SOFs.  This means the PLL is locked to the right frequency and the transceiver can at least receive.

    Running the DCO off REFO made no functional difference.  (Since I want to enter LPM3 when there's no runnable task this is a no-go anyway.)

  • I just also tried setting MCLK to 3MHz - that doesn't work AT ALL - I don't even get a VBON interrupt. That's TOTALLY screwed up. Same at 6MHz. At 12MHz it works as usual - no setup interrupts. This screams clock domain problems.

    I think I'm done with this. It's a dead end.
  • Hello Jan,

    Sorry that you are having trouble getting the USB to work properly in the code base you are using. We recommend using our USB stack for proper USB functionality.
  • 1. The code isn't maintainable: it's poorly understood spaghetti. It has lots of unused functions, like support for crystal frequencies that will never exist, and where the autodetect is just another thing that can break. Basically, it looks like someone's school project. Not practically usable.
    2. The device can't be programmed solely from the documentation. This is the big showstopper, because it means there is poorly understood functionality.

    This makes it a no go. MSP430 is no longer on the map.
  • Hello,

    Thank you for your feedback of our USB stack. the USB Peripheral and the USB stack were developed together and it is not recommended for most users to develop their own. The USB stack was made with the objective to allow variety of developers with a variety of different hardware configurations to use an USB interface on an MSP430 MCU without knowing the ins and outs of USB peripheral within the associated MSP430s. A black box functionality for the HW control if you will. The stack was also developed for the bulk of MSP430 applications that do not have a scheduler, RTOS, or code structure that you are implementing. We do offer another version of this USB stack that is contained with TI-RTOS for MSP430, that is more suited for these type of applications. I suggested checking this out further for your application needs.

    In addition, I checked the known errata for this chip and saw that your situation is very similar to USB8 errata. Can you check the revision of the chip to see if you are affected? As a test, you may want to implement the workaround as well.

    Currently, we cannot support development of a custom USB stack.

**Attention** This is a public forum