• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 78 subscribers
  • Views 1354 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

msp-exp430F5529 unknown device response using debugger interface (Serial side issue)

Stephen Phillips1
Expert 1250 points
Other Parts Discussed in Thread: MSP430F1612

I've been using this for development for several weeks. Today (these things always happen early in the morning ) I was attempting to read data via the 'internal' serial connection and suddenly started getting an unknown device error under win XP SP3. I tested another board (same dev kit) and it did not have an issue (installed the device poped up and USB composite device instead of unknown device). I am pretty sure "rebooting" (windows solution) didn't do a thing (LOL).

In any case it seems something got mangled with the built in FET interface. Does anyone have a suggestion on how to fix the FET side of things (or for that matter 'what happened possibly). The F5529 section seems to work but I cannot program as the board is (sigh). I was hopping to debug the serial interface.

Side note I couldn't seem to get the serial port to work at any baud rate, so the I am assuming that I have to turn off the VLO use for ACLK? I am using smclk for the source to USCA1, however I have REF0 clock going to the DCO and the FLL set to 225 (32768 * 225 = 7372800). The bit rate seems to be 3818 not the 4800 I expected (BR divider is 96 and I'm using x16 over sampling mode) which would indicate something like  5864448 instead of 7372800 for the clock speed (head scratching). Could this be from how I programed the UCS I set it for 

#ifdef    __MSP430_HAS_UCS__
    // DCO =    MCLK
    // DCO =    SMCLK
    // ACLK =    VLO
    UCSCTL4 = SELM__DCOCLK | SELS__DCOCLK | SELA__VLOCLK;
    //
    UCSCTL5 = DIVM__1 | DIVS__1 | DIVA__1 | DIVPA__1;
    //
    UCSCTL6 = XT2OFF | XT1OFF;
    // CLEAR faults
    UCSCTL7 = 0;
    // SRP 2012-1204
    // DCO  = 7372800
    // use REF0 as input
    // set FLL to 225
    // set to use the REF0 as DCO reference
    UCSCTL3 = SELREF_2;
    // low mod
    UCSCTL0 = 0x0000;
    // loop until DCO stabilizes
    do
    {
        // clear oscillator fault flags
        UCSCTL7 &= ~(XT2OFFG + XT1LFOFFG + DCOFFG);
        // clear fault flag
        SFRIFG1 &= OFIFG;
    }
    // while the oscillator fault flag is set
    while((SFRIFG1 & OFIFG)
        // and it's the DCO
        &&(UCSCTL7 & DCOFFG));
    // disable FLL control loop
    __bis_SR_register(SCG0);
    // set DCO to 2.5 to 6 or 23.7 to 54.1 mhz
    UCSCTL1 = DCORSEL_5;
    // set frequency multiplier
    UCSCTL2 = (UCSCTL2 & ~0x3FF) | BASE_CLK_MULT-1;
    //  enable FLL control loop
    __bic_SR_register(SCG0);
#endif

My guess is what is wrong is the oscillator is faulting (heh) due to probably not selecting the right range or I didn't set something correctly for adjusting the range. It appears if DCOx = 0 then the max frequency is 6mhz (pretty close to what I calculated) I guess I need to do a bit of adjustment (except I will have to find out what the heck DCOx is ... I could find the select bits ... oh well). I suppose I answered my own question (sad).

Stephen

  • 0
    Guru 227245 points

    The FET interface side jsut uses a plain TUSB chip for USB->ser connection. This chip either gets its firmware from an external I2C EEPROM or form teh PC driver. It seems that for some reason the I2C EEPROM lso *** content (or a bit flipped, so its content fails the CRC check). In this case, teh TUSB chip doesn't load teh FET specific software but identifies itself as a plain vanilla TUSB chip to Windows and expects to get its formware from teh windows driver. but windows doesn't have a driver for it. hence the 'unknown device'.

    Stephen Phillips1 said:
    The F5529 section seems to work but I cannot program as the board is (sigh)

    You can program (btu not debug) the 5529 through its own USB controller by using the built-in bootstrap loader (BSL). You need to put the MSP into BSL mode (see datasheet ad users guide, BSL sections)  and you can upload a new firmware from the PC through USB then.

    Also, there is a PC software for installing a new firmware for the TUSB, but at first the PC must detect the TUSB and load a standard USB->SER driver. Of course it is possible that you damaged the crystal ont eh FET side. Then the TUSB of course cannot work.

    Stephen Phillips1 said:
    My guess is what is wrong is the oscillator is faulting (heh) due to probably not selecting the right range

    Well, for 7.4MHz DCO, the safe range settings are DCORSEL_4 and DCORSEL_5. With the default DCORSEL_2, the DCO is unable to reach 7.4MHz (0.74-3.17MHz is the guaranteed range, even though some MSPs will reach up to 7.38 MHz with this setting)

  • 0 in reply to Jens-Michael Gross
    Expert 1250 points

    Jens-Michael Gross said:

    The FET interface side jsut uses a plain TUSB chip for USB->ser connection. This chip either gets its firmware from an external I2C EEPROM or form teh PC driver. It seems that for some reason the I2C EEPROM lso *** content (or a bit flipped, so its content fails the CRC check). In this case, teh TUSB chip doesn't load teh FET specific software but identifies itself as a plain vanilla TUSB chip to Windows and expects to get its formware from teh windows driver. but windows doesn't have a driver for it. hence the 'unknown device'.

    I suppose that means I have to dig through my information for the 3410 et al. I know the 3410 firmware is NOT just a single serial port as it uses the USB serial device AND it uses the c51 uart for communication to the target processors. It is registered as a composite device. I was using the interface and then it started acting funny (can't remember what exactly happened is the problem).

    Jens-Michael Gross said:
    You can program (btu not debug) the 5529 through its own USB controller by using the built-in bootstrap loader (BSL). You need to put the MSP into BSL mode (see datasheet ad users guide, BSL sections)  and you can upload a new firmware from the PC through USB then.

    I am using it with debugging (the whole point of using the setup in my view).

    Jens-Michael Gross said:
    Also, there is a PC software for installing a new firmware for the TUSB, but at first the PC must detect the TUSB and load a standard USB->SER driver. Of course it is possible that you damaged the crystal ont eh FET side. Then the TUSB of course cannot work.

    This is the proverbial 'chicken' vs 'egg'. I wonder if TI has a 'base' driver that can be used to program the EEPROM with the proper image. Obviously the driver from the PC (boot strap mode) exists, it would be handy if that sort of 'quick and dirty' mode existed. I know a number of processors that do that for boot strap programming (so it seems to me the 3410 should do that too heh).

    Anyhow debugging wise apart from removing the EEPROM programing a new one and soldering the new one on ... hmmm.

    I'll have to examine the board more, it is disconcerting it happened too say the least.

    Jens-Michael Gross said:
    Well, for 7.4MHz DCO, the safe range settings are DCORSEL_4 and DCORSEL_5. With the default DCORSEL_2, the DCO is unable to reach 7.4MHz (0.74-3.17MHz is the guaranteed range, even though some MSPs will reach up to 7.38 MHz with this setting)

    Right I had a longer look and they don't give nice 'bands' of frequencies to use with the DCO It appears the issue is that with

    UCSCTL0 = 0;

    The range is 2.5 to 6mhz with SEL = 5. That means I should set UCSCTL0 to 0x100 or 0x200 to change the range to 3.1667 to 7.52 or 3.8333 to 9.04.  It is a bit strange they didn't include the band range change as you adjust the resistor tap for the DCO. (sigh) I had to figure it out using ye olde spread sheet and linear interpolation. I can understand WHY they didn't give it (because it is kind of annoyingly difficult to do). Anyhow I need to adjust not just the SEL range but also the DCO tap because it doesn't adjust itself.

    I'll have to try this on a different board however until I figure what happened to the one that decided not to work anymore.

  • 0 in reply to Stephen Phillips1
    Guru 227245 points

    Stephen Phillips1 said:
    I know the 3410 firmware is NOT just a single serial port

    indeed. The default harware UART of the TUSB is used for PC<->MSP1612 communication while the chips I/O ports are (ab)used for a secondary bit-banging serial port.

    Stephen Phillips1 said:
    I wonder if TI has a 'base' driver that can be used to program the EEPROM with the proper image.

    Almost.
    The default TUSB driver is sufficient to communicate with teh MSP430F1612 on the FET. Just the standard device isn't recognized by the PC software. However, the firmware update of the 1612 can be done through the standard driver, if necessary. And then, the 1612 can be instructed (still through the standard driver) to upload a new firmware to the EEPROM.

    It's just a matter of using the right (PC) tools. Unfortunately, there is no complete toolchain with exhausting instructions. AFAIK, you'll have to load all this separately. It has been discussed in several older forum posts, so if you search for 'firmware updater' or 'EEPROM', you  should find the details.

    Stephen Phillips1 said:
    The range is 2.5 to 6mhz with SEL = 5.


    So you have to read it differently. For DCORSELx=5, DCOx=0 will result in one single frequency that is somewhere between 2.5 and 6MHz. DCOx=1 would be between ~2.6 and ~6.1MHz etc. If you need a frequency of 5MHz, this DCORSEL band isn't the right one for you as worst case even the lowest DCOx won't go below 6MHz.
    For each DCORSELx, there are exactly 32 discrete (but unknown/uncalibrated) frequencies available by setting DCOx. To allow for frequencie sbetween these, the modulation switches between the selected and the next higher frequency by a modulation pattern, resulting in 32 different averaged frequencies (over 32 clock cycles) between the discrete DCo frequencies.
    The FLL will adjust the DCOx tap from 0 to 31 and the modulation between the taps. That's why there is a FLL: finding the best DCOx and MODx combination. It just won't change the DCORSEL band selection (which must be done with some caution anyway, to not exceed allowed maximum speed during the switch: set DCOx to 0 and MCLK to at least DCO/2 before switching DCORSEL).
    To pick the correct DCORSELx, you must look at the max frequency for DCOx=0 and the min frequency for DCOx=31 for each DCORSELx. This gives the range in which all 32 DCOx taps will be for sure. However, add a small margin (see the factor for DCOx->DCOx+1) as DCOx=0 and DCOx=31 are considered an FLL/DCO fault condition (if the FLL adjusts to the highest or lowest DCOx tap, it usually indicates that your'e on the wrong DCORSEL band, and the FLL cannot go further up/down)

  • 0 in reply to Jens-Michael Gross
    Expert 1250 points

    Jens-Michael Gross said:
    I know the 3410 firmware is NOT just a single serial port

    indeed. The default harware UART of the TUSB is used for PC<->MSP1612 communication while the chips I/O ports are (ab)used for a secondary bit-banging serial port.[/quote]

    I believe they use the internal serial port on the C51 core processor. That in the larger scheme of things is pretty much irrelevant (it has a fairly limited baud rate and no DMA support). P3.0 and P3.1 are the port pins. Erstwhile ...

    Jens-Michael Gross said:
    It's just a matter of using the right (PC) tools. Unfortunately, there is no complete toolchain with exhausting instructions. AFAIK, you'll have to load all this separately. It has been discussed in several older forum posts, so if you search for 'firmware updater' or 'EEPROM', you  should find the details.

    Much too my chagrin there isn't an 'easy' "omn-itool" for doing so. I'll live, it just will take a bit to work through "fixing" it (and time). Good thing I have a spare (or 2).

    Regarding the DCO/FLL the DCOx selection seems to like 6, it does take a bit of time to stabilize so my 'initial' guess may be a bit off. It does work and syncs within about 10-15ms. A bit slow but livable. I think it would be nice if TI offered a 2nd DCO that you could use to sync to an outside source one could use for whatever purpose. (I was thinking like I2S interface sync or other clock sources).

    Thanks again for the incite.

    Stephen

  • 0 in reply to Stephen Phillips1
    Guru 227245 points

    Stephen Phillips1 said:
    Regarding the DCO/FLL the DCOx selection seems to like 6, it does take a bit of time to stabilize so my 'initial' guess may be a bit off. It does work and syncs within about 10-15ms.

    Hmmm, I had expected it to be a bit faster:
    (6*32)/32768 = 5.8ms. Plus maybe a few more MODx steps. That's what to be expected when the FLL has to adjust from DCOx=0 upwards. One MODx step per reference clock, one DCOx step per 32 MODx steps.

    If you know (check the datasheet values) that beginning with DCOx=6 won't exceed the currently allowed maximum clock in worst case, you can set DCOx to 6 right at the beginning. Then the settling time will be significantly reduced. It still depends on the actual MSP, VCC, temperature. However, it won't guarantee faster settling for all circumstances. Depending on how much the devices stray from each other, starting with 5 or even 3 might give the best maximum settling time while 6 might give you the best average settling time, now that you know that 6 is the final value on your specific MSP.

    Stephen Phillips1 said:
    I think it would be nice if TI offered a 2nd DCO that you could use to sync to an outside source one could use for whatever purpose.

    What exactly do you mean? The USCIs can run from external clock input, the timers too. However, that's an 1:1 input or a fraction of it.
    Or do you mean a PLL frequency multiplier that locks to a multiple of an input frequency? Those babies are nice, but eat power like crazy. Definitely nothing for the low-power MSP series.

    BTW: you're not limited to the REFO as FLL reference. You can as well pick XT1 in HF or bypass mode or XT2 (also in HF or bypass mode) as reference, in addition to REFO or XT1 in LF mode. So you can generate 25MHz from a 1MHz external clock if you want.

**Attention** This is a public forum