MSP-EXP430F5529LP SPI clock rate for SD Card

Oh, and one more *really* annoying thing... after changing the divider to 12.5MHz, in addition to no longer being a valid file system, the USB FET driver no longer gets loaded so I can't debug or load new code. This renders my module a brick (albeit a very light one). This has happened to two modules. Once is a coincidence. Twice is a pattern. I tried re-installing the drivers and everything else but it didn't work. Any help with that problem would be greatly appreciated.
thanks,

A typical SD card runs with up to 25MHz SPI speed. Only during initialization, SPI speed is limited to 400kHz.
However, i can be that the code simply can't run that fast and locks up when the SPI data comes faster than every 24 MCLK cycles.
My own SD card access was successful running with 16MHz MCLK and 16MHz SPI clock.
If the code locks-up during card access, it may prevent the device from properly handling the USB functions, so it won't enumerate. IIRC, the board has an onboard HUB for joining FET and target USB into one USB connector. This may prevent JTAG access.
However, the USB BSL should still work for uploading a new firmware, as it is started and executed before your user code is executed. It requires, however, powering the device from USB and pressing the 'BSL switch' while plugging it in. (not sure the board has one).

Thank you.  Pressing the BSL switch works to re-enable the USB FET debugging.  I should buy you a beer for that.

The SD card (or at least the software example I'm running) won't run at 12.5MHz with a 25MHz CPU clock.  That seems odd to me.  The code itself doesn't use DMA or anything fancy, just a couple of loops to poke the data into the registers.  What curious is that the code contains this (including the comments):

void SDCard_fastMode (void)
{
  UCXxCTL1 |= UCSWRST;  //Put state machine in reset 
  UCXxBR0 = 2;          //UCxCLK = 25MHz/2 = 12.5MHz
  UCXxBR1 = 0;
  UCXxCTL1 &= ~UCSWRST; //Release USCI state machine
}

That should actually read 25MHz/3 = 8.33MHz according to my reading of the processor user guide but I've been tripped up before.

Thanks. But I'd need a new liver if everyone would keep this promise :)
The card itself likely will run at 12.5MHz. But the code, that accesses the card won't work with only 16 MCLK cycles for each transfer. I don't know the code and how it interacts (or interferes) with USB operation.

One example would be that if the data transfer is done by interrupt, and the interrupt priority of the used UART is higher than the USB interrupt priority, it might be that there's always an UART interrupt pending at the higher rate, and the USB interrupt is never served. At lower SPI clock, the UART ISR is done before the next interrupt and the USB ISR can be entered. Just a fictive scenario,as I don't know the real code.

I just checked again, and I have a note in my doc error log. It seems that the formula in the datasheet is incorrect, and fBitClock is fBRCLK/UCBR, except for UCBR=0 (UCBR=0 is the same as UCBR=1). At least this is what experiments have revealed.
So you're running the SPI with 12.5MHz already, and try to go for 25MHz, leaving only 8 MCLK cycles per byte.