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.

MSP430FR2433: Sometimes first bit error on MISO when FR2433 acts as SPI slave

Part Number: MSP430FR2433
Other Parts Discussed in Thread: MSP430F5232, , MSP430FR2311

Champs,

I am asking this for our customers.

We use FR2433 acting as SPI slave by eUSCI_A with UCCKPH=1,UCCKPL=0;

It's weird that sometimes the first bit of MISO is wrong.

Like below, FR2433 should send 0x40, but it sends 0xC0, which is wrong, and the host MCU (SPI master) also read 0xC0.

This symptom only occurs when we connect to a host MCU, but we do not observe it by using an external SPI master emulator with TI FR2433 Launchpad and send SPI commands one by one manually.

We notice the USCI47 on the errata.

http://www.ti.com/lit/er/slaz664l/slaz664l.pdf#page8

But even we tried to use the workaround by forcing SCK low first and then reset MSP430, it does not help.

Note that the same host MCU (same SPI code) can be used to connect to MSP430F5232 (USCI acting as SPI slave), though it's on somewhat different board design.

We just ported F5232 codes onto FR2433.

Do you have any suggestion for us to debug this?

Do you think this is USCI47 erratum?

Is this a timing related issue between host MCU and MSP430FR2433?

What's the difference between F5232 SPI slave and FR2433 SPI slave here?

Wayne

  • Hi Wayne

    I have setup the test by MSP430FR2311 which have same errata USCI47 with the code example of "msp430fr231x_euscia0_spi_10.c" and just change the UCCKPH=1,UCCKPL=0. The result is no problem. I have power on again for three times. What's the other configuration in your EUSCI like clock speed and MSB first selection?
  • Gary,

    Excuse me, I accidentally touched the resolved, but this issue has not yet resolved.

    1. I want to confirm USCI47 seems the first bit missed and then the data shifted, but we just miss the first bit sometimes. Do you think this is related to USCI47.

    2. Our clock is SMCLK/2 = 8MHz. The SPI master clock is about 1.2MHz.

    3. I upload more figures below.

    Below, the data 0x48 is expected value, but your can see the timing the MISO data is very close to the rising edge of the clock. The is, the timing is very tight.

    Below, the data 0xE2 is not correct. (correct should be 0x62).

    You can see the MISO data pin changes later than the rising clock.

    Do you have any suggestion for us to debug?

  • Hi Wayne

    Does the MSP430 going into low power mode after receive the data? It is strange for the second picture. Does the wire between the master and slaver long or just on the same PCB? I will try to reproduce this bug on my side.
    Can the customer change the configure of the SPI like change the UCCKPH=0 ?
  • Hi Wayne

    Maybe I have found the reason.Can you help me to verify it?

    Due to the first bit change on MISO is the time you move the data to the UCxTXBUF like below:

    Maybe the reason is there is no enough to move the data to UCxTXBUF.

    To verify this you can follow the test below

    1. enable the RX interrupt, update the UCxTXBUF immediately when send out the previous data.

    2. increase the interval time between two bytes data transmission.

  • Hi Wayne

    I have check this issue is not the USCI47's case. Because this issue is not meet the second the condition of the USCI47. And the failure mode is not the same(This issue just miss the first bit and not shift).
    For your use case(you can't make change in the master side), I have some suggestions here:
    1. configure the MCLK to 16MHz to increase the data processing capability
    2. Move the output data into the UCxTXBUF as soon as possible you can just out put 0xf0 and 0x62 for test
  • Gary,

    Your are right.
    After testing, we solved this by either
    1) SPI master increase the time interval between bytes
    2) configure the MCLK to 16 MHz

    Thank you very much for your support.

    Wayne Huang
  • Gary,

    More update.
    After more testing, we found there is still first missing bit if we only configure the MCLK to 16 MHz.
    So, we will ask the SPI master to increase the time interval between bytes.

    Wayne
  • Hi Wayne

    That sounds we found the root cause:The process time for MSP430 is not enough.
    The code optimize in the MSP430 process will to solve the problem too.
    So I will close this thread now, you don't need reply this.


    Best regards
    Gary

**Attention** This is a public forum