ATtiny817: SPI Receive Interrupt Flag is not set

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

 

I'm using a ATtiny817 and want to read data from a sensor via SPI protocol (3 bytes from a AS5311). This works nice. The ATtiny817 also acts as I²C slave and data is read after the MCU signals new data by sending a falling flank on the pin (PIN_FRAME_READY).

 

This works nicely for a while until suddenly the SPI peripheral stops setting the receive interrupt flag (SPI_RXCIF in SPI0.INTFLAGS). This might happen after hundred SPI reads or after thousands of SPI reads. In error case still data can be send out, but the interrupt flag is not set. I see no difference in the SPI registers for the working and for the non-working case. I tried to bring the RXCIF back by deactivating and reactivating all ISR and by writing all SPI configuration registers to zero and setting them new. There was no effect on the RXCIF at the next transfer.

I have observed this only in combination with I²C slave transfers. Therefore I can't further simplify my example code.

 

Description of the code:

- each millisecond the RTC sets the periodic interrupt flag and this is tested in the main loop.

- - SPI gets activated and the chip select is activated. I push zeros to SPI0.DATA as there are only bytes to read. Here I'm incrementing the number of started SPI transfers (spiStarted).

- - In the SPI ISR a subsequend byte transfer is triggered. If the buffer is full (3 bytes) a GPIOR flag is set indicating that the transfer is completed (FLAG_SPI_COMPLETED).

- - A completed SPI transfer will lead to a increment of the spiEnded variable.

- each 10 milliseconds the I²C send buffer is filled with the current value of spiStarted and spiEnded

- - A transient on a pin (PIN_FRAME_READY) signals new data, which is then read by the I²C master. After this the pin is cleared again.

 

What do I observe:

- After a reset the I²C master reads increasing numbers (spiStarted and spiEnded). After a random time the spiEnded is stalled while the spiStarted is still running.

- A logic analyzer on the SPI bus shows reads of three bytes. After the error occured there are only transfers of two bytes.

 

I tried to remove irrelevant code and keep explaining sections. Therefore there are some unhandled conditions where I see no connection to the error.

 

Do you have any idea why the interrupt flag is not set after a SPI byte write?

Thanks a lot.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Since you did not show any code, any anything offered would be a guess,

I will only say that few of us use interrupts with SPI as its fast enough that a quick spin wait is all that is needed.

 

Jim

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Jim,

 

There is attached the code. Even if I don't use ISR, I need to know, when the byte is transfered.

Last Edited: Mon. Jul 17, 2017 - 07:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why use interrupts for SPI?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Make sure the SS pin is defined as an output, if it is an input (default) then a low level will force the SPI into slave mode!  (don't let it float)

 

 

Jim

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You're right, that saving the SPI could be a workarround.

I will try this tomorrow but I don't see why the RXCIF should work more reliable in polled mode.

Maybe the data register empty interrupt flag (DREIF) can give reliable information.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Jim,

 

indeed my SS pin is floating, but I've set the SSD in the CTRLB (in the setup() method).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mmj wrote:

indeed my SS pin is floating, but I've set the SSD in the CTRLB (in the setup() method).

 

That is a new feature, I would still set SS pin to be an output, and check the DRE flag before writing data to the data reg.

 

Jim

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Jim,

 

I've implemented it synchronous checking the RXCIF flag and got the error. Checking the DREIF synchronously in buffer mode works nice. For the last byte I have to check RXCIF or TXCIF (or use a static delay). In this case I used the RXCIF and have not observed any error.

So now I have a implementation where I haven't observed the error.

 

I've also tested the correlation between the SSD flag and the /SS pin direction/value (also checked influence of MOSI direction) and the error happens independently.

 

regards

mmj