• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 81 subscribers
  • Views 736 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.

SPI Rx interrupt problem on F28069

Simone Navari
Prodigy 20 points

Hi to everyone,


I'm experiencing a strange issue on F28069 (Rev. A) SPI peripheral: if I set a too low SPIBRR register on a device configured as slave, the receive interrupt stop to fire after a small amount of time. I see that RXFFINT flag is set but  PIEIFR6.bit.INTx1 stucks to zero !

I checked all registers and they seem to be ok:

- RXFFIENA = 1
- SPIFFENA = 1
- PIEIER6.bit.INTx1 = 1

Receive fifo level threshold (RXFILL) is set to 2 and when interrupt stops to fire, RXFFST value is 4 so it's normal that RXFFIENA is set and interrupt should fire, isn't it ?

I did some experiments and I discovered that if I reset FIFO writing a 0 and then a 1 in RXFIFORESET, interrupts restart to fire only for a little while.

The bit rate is 9Mbps obtained setting SPIBRR to 4, with SYSCLK = 90Mhz and LSPCLK = 45 Mhz. Playing with SPIBRR I discovered that if I set a value greater or equal to 19 (bit rates >= 2.25Mbps) interrupt never stops to fire ! I dig in datasheet, technical reference and errata but I didn't found anything that limit SPI, or in general interrupts, to frequency lower than 2MHz.

Am I missing something ? Did someone experienced, and resolved the same problem ?


Best regards,

Simone

  • 0
    Guru 30330 points
    Simone,

    SPIBRR has no effect on the SPICLK rate when the module is configured as a Slave. This is clearly documented in the TRM in the register description for the SPIBRR register. It appears that your problem is elsewhere, not in the clock configurations.

    I suspect it is likely in your ISR code. Are you clearing your interrupt and overrun flags inside of the ISR? Can you share your ISR code?

    Thanks,
    Mark
  • 0 in reply to Mark Labbato
    Prodigy 20 points
    Thank you Mark,

    I've found the cause of the problem: it was the RXFFOVF flag that was set but I never reset it using RXFFOVFCLR in ISR. Using a slower frequency, the overflow condition never occours so it's explained why my bugged code works increasing the value of SPIBRR register.

    Thank you again,
    Simone.