• State TI Thinks Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 102 subscribers
  • Views 165 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

AM3357: Slave SPI on abnormal master clock

vincent sertorio
Prodigy 10 points
Part Number: AM3357

Hello,

I have to use a slave SPI communication on the am3357 chip.

The master signal I receive is uneven. It is generated by software from the client side, and suffers from interrupt, see enclosed document.

 

The master SPI generates a clock around 700kHz. After 2 bits, the master stops for about 20µs, then resume the last 6 bits.

Because of this delay, I loose completely the transmission. The client cannot change anything on his code (of course).

1) Is there a way to make this kind of transmission work? 

2) Is there a register to read if this error occurs, so I can clear the interrupt to start clean all over again?

I thank you in advance,

I wish you an excellent day,

Best regards,

Vincent SERTORIO

  • 0
    TI__Guru 50811 points

    Hi Vincent,

    just so I understand this correctly. The AM335x is operated as a SPI slave, driven by an external master, correct?

    If that's the case usually the timing should not be critical as SPI is a synchronous interface, so even if the master clock coming into the AM335x is not "perfect" it should still work.

    What SW are you using on the AM335x side?

    How do you detect there was an error?

    Regards, Andreas

  • 0
    Prodigy 10 points

    Hi Andreas,

    Yes, the AM335x is operated as a slave, and we use it with a real time kernel.

    We found the problem : we were restarting the SPI transaction too early, making the chip interpret the next ticks as a new byte. 

    We added a good use of the EOT flag, thus solving the issue. So far, no more trouble.

    The error was detected by the master system, as the expected replies were false. 

    We still don't understand why the system creates a pulse on the TX signal.

    Thank you for your time.

    Regards, Vincent