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.

MSP430F5xx SPI Clock phase

Expert 1125 points
Other Parts Discussed in Thread: MSP430F5529, MSP430F5438

 

Hi,

 

I have some strange problem with MSP430F5xx SPI Clock phase(UCCKPH).

MSP430F5529(master) and MSP430F5438(Slave) are connected through SPI and I am using sample program uscia0_spi_09 and 10.

When I change the Clock phase to UCCKPH=1(i.e Data is captured on the first UCLK edge),

the communication goes wrong, i.e.I get wrong data.

I have cross checked that both Master and Slave have the same settings.

 

It works fine when the Clock phase is default(UCCKPH=0) and also I tried with a loopback program which also works fine.

I dont understand what is the problem with the setting UCCKPH=1.

 

Please let me know if this is a bug or something else I am missing.

 

Thankyou.

 

  • It might well be that you're off by half a bit when using UCCKPH=1, depending on the current clock line state when the hardware is initialized.

    Settign the UCCKPH bit will (at least I believe) cause a level change on the clock line. which might be misinterpreted as the first clock cycle by the slave etc.

    Which wrong data do you get? Sometimes looking at the 'bits that come' is enlightening.

  • To add to Jens' post, the best practice here is to make sure the the Master has properly initialized its SPI state-machine first before configuring the Slave state-machine.

    One way is to use a GPIO pin from the Master connecting to the Slave to tell the Slave that it has properly started. Then, the slave can intialize the SPI state-machine.

    Regards,

    William

  • William Goh said:
    One way is to use a GPIO pin from the Master connecting to the Slave to tell the Slave that it has properly started. Then, the slave can intialize the SPI state-machine.


    Usually, this is done by the chip select signal. It should reset the slaves state machine, enable its clock input and data output and should also reset the (sofware) protocol.

    The MSP SPI hardware does not directly support this. The STE pin only enables/disable the clock and the output, it doe snot reset the state machine and of course not the protocol, as the SPIU hardware doe snot know whether a state machine reset is necessary or what the protocol is. So an MSP acting as SPI slave should detect the STE lien change by software (e.g. by routing it to an interrupt-capable port pin) and do the necessary adjustments as fast as possible (reset the SPI, put the first data byte into TXBUF etc.). It cannot reach the CS-to-clock time of a few nanoseconds which is usual for many hardware slaves, but if the master knows about it, it is no problem.

**Attention** This is a public forum