MSP430G2553: Problem with SPI bus in the TSSOP version

Since the Launchpad doesn't (natively) accept a TSSOP, you probably need to explain what "replace" means. 

Is the TSSOP on a (DIP) adapter board that you put into the Launchpad? If so, I'd start by checking solder joints.

Or is it on a separate board? If so, I would be looking for Launchpad artifacts that make it "accidentally" work there. And solder joints.

I'm using a simple adapter from DIP20 to TSSOP20. I remove the original MCU and I replace it with this adapter. I checked all the solder joints many times. The circuit is OK...

I don't know of any reason they would be different. We've used the DIP and the TSSOP-28 (not the -20), and move the code around, but not in the same circuit (pins are different).

Do you have a symptom for the SPI failure? Is it occasional wrong bits, or solid stuck-high/low? Which USCI are you using?

Do you rely on the 32kHz crystal? Oscillators are finicky, and I suppose it's possible the longer traces make a difference. 

I'm using UCB0. The problem is not occasional, but systematic.... and only with the Bmi160 sensor. In the TSSOP mcu the code "flows" regularly, but when I try to read a bmi160 register the response is even 0 or -1. Conversely, with  the DIP20 version I read the correct register value. Maybe, I have to verify and compare the spi signals in the two cases, right? I have the oscilloscope.

Scope traces may be the fast path to an answer. A hypothesis can come after-the-fact.

After reading BMI160 data sheet section 3.2.1, I'm wondering if (in the failing case) the sensor is going into I2C mode. The detection sequence seems susceptible to timing errors.

Yes, the problem was noise on the TSSOP's SPI clock....maybe the BMI160 is noise sensitive. I solved the problem by using an external LDO and by reducing the SPI communication speed.