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.

TMS320F280230: question about spi

Part Number: TMS320F280230

Dear TI engineers,

I have a doubt in my work about spi between 28337s and 280230 or 280270. 

Normally, communication of spi work well like pic1 below.

But, it could also not work like pic2 blow.

When fault happened, the SPIFFTX.BIT.TXFFST would be 4 which is the max value. So, data could not transmit. If fault have not happened, the SPIFFTX.BIT.TXFFST would be change from 0 to 4 in loop and data could send successfully.

So, do you have some idea?

Waiting for yours, best wishes,

coke.

  • I'm assuming the slave device is the TMS320F280230, is that right?

    What is the status of the other bits in SPIFFTX?

  • Hi,

    Gus, thanks for your reply.

    Status of the bits shown below at pic1 in SPIFFTX are same in right and wrong state. Difference between them is whether bit of TXFFST could be changed to 0.

    pic1

    Configuration of spi was shown below in pic2.

    pic2 

    Waiting for yours, best wishes,

    coke.

  • Can you make sure the SPIPRI.FREE bit is set to 1?

  • Hi,

    Gus, you are right. Though I add  spiaregs.SPIPRI.FREE =1 in both 28337s and 280230, the fault also happened as before.

    Waiting for yours, best wishes,

    coke.

  • The only other thing I can think of is that the SPI is not receiving SPI_CLK signal. Can you double check the GPIO pinmux configuration for the SPI pins? How does the F280230 connect to the SPI bus? Is it on the same same board? Is it connected via wiring?

  • Hi,

    Gus, glad to hear your reply.

    Configuration of GPIO have been shown in pic1. I have not thought this is the core of fault.

    The four wires of spi in 28377s and 280230 is connect by 0 ohm resistance in the same board and have short distance. Certainly, GPIO of spi have been pulled up by 3.3v. 

    The only other thing I can think of is that the SPI is not receiving SPI_CLK signal.

    What did you mean for this idea? From the pic above, SPI_CLK signal have successfully sent by 28377s. But it could not confirm whether this signal have been received by 280230?

    Waiting for yours, best wishes,

    coke.

  • Thanks for confirming both MCUs are on the same board.

    What did you mean for this idea? From the pic above, SPI_CLK signal have successfully sent by 28377s. But it could not confirm whether this signal have been received by 280230?

    My only thought was that somehow the GPIO mux configuration was not taking effect and that the GPIO18 was not actually configured as SPICLK, hence F280230 SPI was not actually seeing SPI_CLK. Your configuration look ok though. Maybe just double check the GPIO CTRL registers using the debugger when you detect the error condition to make sure this is not an issue.

    Can you share the F28030 code where the SPI TX BUF is loaded with new data?

  • Hi,

    Gus, the picture below shown the GPIO CTRL registers in expressions window. It seemed like no problem.

    The picture below shown the code.

    Waiting for yours, best wishes,

    coke

  • Hi,

    Gus, did you need some other information about this question?

  • Apologies for the delayed response here. I am not quite sure what could be the cause of this problem. I have reached out to other colleagues to see if they have any suggestions on what to try next, but I have not heard back. The only suggestion I have is to try to replicate this problem on a simpler code set (maybe by modifying one of the C2000 SPI examples) and send over to see if we can replicate the issue on our end. 

  • Hi,

    Gus, I would do the work which you suggested as soon as possible.

    best wishes,

    coke