AVR128DB48 (and many others): SPI-IF not cleared by hardware as described in the data sheet

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

The problem may have been known for a long time or maybe it's any mistake on my part: When programming an SPI data exchange, I noticed that the IF flag is not cleared by hardware when the SPI interrupt is executed, as described in the data sheet. The interrupt is repeated at high frequency instead. The alternative (first read the INTFLAGS register, then access the DATA register) works. This data sheet functional description can also be found on other AVR controllers... I'm a bit clueless as to how this error come about frown

 

This topic has a solution.
Last Edited: Fri. Apr 22, 2022 - 06:00 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
SPIINT: push    ...
        sbi     VPORTA_OUT,7          ;RESET /SS = INACTIVE
        ldi     YL,low(CPU1BUFP)
        ldi     YH,high(CPU1BUFP)     ;Y= ADDR(CPUBUFP)
        lds     ZL,CPU1BUFP
        lds     ZH,CPU1BUFP+1         ;Z= CURRENT ADDR(CPU1TBUF)

        lds     XL,SPI0_INTFLAGS      ;It won't work without this line
                                      ;IF is not reset otherwise!

        lds	XL,SPI0_DATA
        std     Z+18,XL
        adiw    Z,1
        cp      ZL,YL
        cpc     ZH,YH
        brlo    m2
        ldi     ZL,low(CPU1TBUF)
        ldi     ZH,high(CPU1TBUF)     ;RESTART RINGBUFFER ADDR
m2:     std     Y+0,ZL
        std     Y+1,ZH                ;SAVE NEXT RINGBUFFER ADDR  
        pop     ...
        reti

 

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

I also experienced it. There is a lie in the data sheet.
It is automatically cleared when the interrupt flag register is read in the interrupt service routine.

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This data sheet error of all newer AVR series now has not been corrected for years and can already be found in the 4808/09 angry

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

error of all newer AVR series now has not been corrected for years and can already be found

What does that mean?  Has it been corrected or not---sounds like a no?  Is there a way to denote which sheets are correct (such as all after 2021?) or are all incorrect?

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

It seems that until now there is no correct data sheet for all newer AVR series 0/1/2...

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

No one may have reported to Microchip.
I knew the problem, but I ignored it because it didn't hurt.
Because I don't neglect to check the interrupt flag.

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

Developing with false data sheet can be so insidious...

The only one valid reset method is just as unusual.

Usually writing a '1' to IF clears the flag-

if the hardware does not do it as described (which would also make the most sense).

 

kabasan wrote:
No one may have reported to Microchip.

 

I just did it.

Last Edited: Mon. Apr 18, 2022 - 09:22 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

GermanFranz wrote:

SPIINT: push    ...
        sbi     VPORTA_OUT,7          ;RESET /SS = INACTIVE
        ...
        lds	XL,SPI0_DATA
        ...
        pop     ...
        reti

Is this for SPI Slave Mode ?

I see only a read of SPI0.DATA but there is also a write to SS. I'm a bit confused about that, surely SS is an input in Slave Mode.

 

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

SPI is in Master-Mode. /SS is output.

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

OK That makes sense from the /SS point-of-view. Is this a single byte transfer with the SPI data register write, happening elsewhere ?

 

Reason: If I get time I might try this in the Atmel Studio Simulator.

 

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

N.Winterbottom wrote:

Is this a single byte transfer with the SPI data register write, happening elsewhere ?

 

Yes it is a single byte transfer.

There is a second part in an other interrupt writing periodic to SPI0_DATA.

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

GermanFranz wrote:

kabasan wrote:
No one may have reported to Microchip.

 

I just did it.

 

I received confirmation from Microchip with the promise to revise the data sheets.

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

N.Winterbottom wrote:
Reason: If I get time I might try this in the Atmel Studio Simulator.

Well that was a dismal failure. I could not get the SPI IF flag to become set. Of course the ISR did not fire. I'm beginning to think this is a failure of the simulator.

 

PS: I did read in the Interrupts Section of the datasheet that the Hardware NEVER clears ANY interrupt flag automatically.on ISR execution.

 

I can't post the exact section right now

 

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

N.Winterbottom wrote:

I'm beginning to think this is a failure of the simulator.

 

I would always test such very hardware-specific things with real hardware.

 

N.Winterbottom wrote:

PS: I did read in the Interrupts Section of the datasheet that the Hardware NEVER clears ANY interrupt flag automatically.on ISR execution.

 

You're right:

"The interrupt flags are not automatically cleared after the interrupt is executed. The respective INTFLAGS register descriptions provide information on how to clear specific flags"

 

A contradiction in the data sheet that should be immediately apparent.  But it didn't.  For many years, for many data sheet revisions, for many Series 0/1/2 controllers...