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.

CCS/MSP430F5529: MSP430 MSPware USB-stack why is USB using some of my peripherals like TimerA1?

Genius 4170 points
Part Number: MSP430F5529
Other Parts Discussed in Thread: MSPWARE

Tool/software: Code Composer Studio

Hello texas-team,

over the last couple of months I kept on seeing weird stuff happening in my MSP430 devices once enabling the USB via the code-line:


in there comes some interesting behaviour:

uint8_t USB_setup(uint8_t connectEnable, uint8_t eventsEnable)
    uint8_t status;

    status = USB_init();

    if (eventsEnable) {
    if (connectEnable) {
        if (USB_getConnectionInformation() & USB_VBUS_PRESENT){
            if (USB_enable() == USB_SUCCEED){

    return (status);

The USB_init() contains the following lines, already a bit altered by me, since the automatic chrytsal detectino wouldnt work in my case:

    USB_XT2Freq = USB_determineXT2Freq();
    USB_XT2Freq = 24;
    USB_XT2PLL = USB_lookUpPll(USB_XT2Freq);
    uint16_t MCLKFreq = USB_determineFreq();

now the determine XT2Freq really break my code since it is using the TimerA1 which I do use in some other mannor already:

in the folder: USB_API/USB_common/usb.c

// Timer A1 Settings - Used for XT2 Frequency Auto Detect
#define TIMER_CTL           TA1CTL
#define TIMER_CTL_CLR       TACLR
#define TIMER_CCTL          TA1CCTL2
#define TIMER_CCTL_CM       CM_1
#define TIMER_CCR           TA1R

there it states what timer is used for those purposes, sadly I havent realized earlier.

Just wanted to know, hwo am I supposed to work with that?

My current workaround would be to rewrite the USB_code, so that no automatic chrystal determination is needed, since I do know my chrystals very well.

Then I will use the timer only for my purposes.

The other thing I could do is initialize the USB-code right at the beginning ( I do it rather at the end and furthermore I can toggle USB on and off in my code in different locations, so that will of course trigger the USB again and destroy my peripherals again)

and after the USB initialization I will init all my ADCs and Timer etc.

What would you suggest, how does Texas use their USB.

In all the examples I have never seen the usage of TimerA1 after the USB_init.

Thanks for reading,

best wishes.

  • Hi Seb, I am not familiar with USB library in MSPware, on the question "TimerA1 usage on  the USB_init", Please give me several days to check the document and code. Thanks!

  • Update 1:

    I found a current docoumentation in which the peripheral usage of the USB_stack is explained:


    This document exists in various versions in the earlier versions 2012 and 2015 the former USB_stack did not make use of any TimerA peripherals, in the current version it does.

    Sadly I did overlook that fact for a while, the rest of the code basically stays the same, so it is one kind of those bugs that are hard to find, since the general code is working well.

    TimerA: Is used for auto-detection of the XT2 frequency

    I imagine that everyone who uses the USb_stack certainly knows of his XT2 frequency, so why is this code in there anyway?

    Anyway a simple workaround is to simply delete the line and insert your own known frequency and everythign will work as planned.

  • Hi Seb Very glad to know you have find the approach to solve time A problem.

    This is the quick comment from TI expert:

    The USB stack as pointed out only uses TimerA to determine what frequency the external Xtal for the USB is at. The USB BSL does the same thing. The customer can take actions of changing the order of initializations so that TimerA isn’t used again, and/or to make sure to re-initialize TimerA to what they want after calling USBinit(). Alternatively, they could hardcode the XT2 frequency within the USBinit() process.

    I think Timer A usage enhances the robustness of the program. but, it is not MUST as XT2 frequency is known.