MSP430F5528 BSL clock

The USB part requires an 48MHz clock. The BSL doesn't know of the hardware, so all it can do is checking whether the external reference it finds against the internal REFO clock to test whether it is ratehr 4,8,12, or 24MHz, so the PLL cna be programmed with a 12,6,4 or 2 factor.
The second crystal on XT1 usualyl is a watch crystal with 32768Hz. It is more stable than REFO and low power and can be used for driving MCLK with a stable DCO-generated frequency that is independent of the USB reference clock. AFAIK the BSL does not need it - REFO is precise enough to tell 4 from 24 MHz USB reference. And for MCLK, no stable frequency is required for the BSL operation.

The BSL will most likely not set the XT2 to bypass mode, but AFAIK, forcing a digital clock signal to XT2IN and leaving XT2OUT unconnected will only result in a higher power consumption for the unnecessarily driven output. The input should be satisfied with any oscillation, no matter where it comes from. Since it is for BSL operation only and this means that you have USB bus power, I'd consider this a don't care.

Hi,

I have a custom built board with the msp430f5528 processor and a 8 MHz crystal connected to XT2. I've successfully implemented a CDC interface where I can communicate with the processor, but when I try to enter the BSL sequence it just won't work. I'm supplying 3.3V externally to the processor, so that it doesn't perform a reset on Vbus_off event. The code works perfectly in the msp-exp4305529 experimenter board, entering the BSL sequence and successfully programming with the python msp430 tools. I'm using ubuntu on a VMWare Fusion virtual machine running on OS X 10.8.

But I can't get the BSL working with my board. The USB interface appears but fails in the enumeration process. I've tested the XT2 clock extensively with no troubles. The XT2_Start_Timeout routine returns successfully after one cycle, the clock stability is tested via a 0.01s square wave and a serial port at 57600 bps, all working OK. The message in OS X is the following:

USBF: 335320.275 [0xffffff80347aa400] The IOUSBFamily is having trouble enumerating a USB device that has been plugged in. It will keep retrying. (Port 1 of Hub at 0x26200000)
USBF: 335321.110 [0xffffff80347aa400] The IOUSBFamily gave up enumerating a USB device after 10 retries. (Port 1 of Hub at 0x26200000)
USBF: 335321.110 [0xffffff80347aa400] The IOUSBFamily was not able to enumerate a device.

I'm using a CSTCE8M00G52Z-R0 Ceralock crystal from Murata, which has an integrated load capacitor, so I'm discarding any load capacitor mismatch. I've tried with the 33pf and 10pf variants, with no luck. I guess there are three possibilities for this failure:

1. The crystal is not accurate enough for the BSL (0.5% tolerance, 0.2% stability), but then the CDC interface wouldn't work, right?

2. There's a problem with VCC in my board.

3. The BSL program is optimized for 4 MHz crystals. Is it possible to modify the BSL sequence, giving it more time to stabilize the XT2 clock?

What I don't understand is why does the USB work for the CDC interface but not for the BSL? I'll appreciate any help with this, I've spent countless hours searching through forums, datasheets and application notes, with no luck whatsoever.

Thank you very much in advance!

Jose

Update: I just found out about the BSL6 issue of the errata sheet, and the device I'm using is affected (Rev. F). The msp430f5529 I'm using does not have this issue (Rev. E), so I'll try uploading a new BSL. If anyone has done this using mspgcc and a launchpad board I'll really appreciate any guidelines. 

Kaly Hong said:

In my hardware setup, my only clock is a 8MHz silicon oscillator feeding the XT2 input, but I noticed that all of the TI target boards have crystal oscillators on both XT1 and XT2 inputs. Will the BSL automatically know to set the XT2 to bypass mode to find the 8MHz clock or do I need to use a crystal oscillator?