SERCOM_SPI_STATUS_BUFOVF when SERCOM is running with lower interrupt priority (ASF3)

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

I have recently experimented with changing the interrupt vector priority level of a SAML21 SERCOM, used as a SPI Master, to a lower level.
The SPI is used to connect external flash.

 

Since lowering the priority the SPI is suffering from SERCOM_SPI_STATUS_BUFOVF events.

This results in the SPI_INTERRUPT_FLAG_RX_COMPLETE callback not being called.

 

The fact higher priority interrupts can interrupt the _spi_interrupt_handler is understood, but I don't think it should overflow.

 

I think the _spi_interrupt_handler in sam0/drivers/sercom/spi/spi_interrupt.c should do a read-before-write operation.

That is:

/* Receive complete interrupt*/
if (interrupt_status & SPI_INTERRUPT_FLAG_RX_COMPLETE) {
    ...
}

before:

/* Data register empty interrupt */
if (interrupt_status & SPI_INTERRUPT_FLAG_DATA_REGISTER_EMPTY) {
    ....
}

 

In my testing this eliminated the SERCOM_SPI_STATUS_BUFOVF.

 

Am I on a sensible track?

If so, and it is considered a bug\improvement to ASF3, what are the next steps?

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

Definitely would be an improvement to handle Rx before Tx, but it won't completely solve the problem. Tx is double-buffered, so on start up will generate two DRE interrupts before Rx even gets going. As a result, Tx will always be two bytes ahead of Rx, and any subsequent delay in servicing the RXC interrupt can result in BUFOVF if you don't keep up.

 

The next step would be to use DMA smiley

 

Steve

Maverick Embedded Technologies Ltd. Home of Maven and wAVR.

Maven: WiFi ARM Cortex-M Debugger/Programmer

wAVR: WiFi AVR ISP/PDI/uPDI Programmer

https://www.maverick-embedded.co...

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

Thanks,

 

Yes still using the ASF job calls - but it is still byte-by-byte, just abstracted away into the ASF code.

 

I can see with the double-buffering there is still a risk of there being a BUFOVF.

So far, in testing, handling Rx before Tx has significantly reduced the occurrence rate (in that it hasn't occurred on our platform, since making this change).

Also looking at enabling FEATURE_SPI_ERROR_INTERRUPT as a BUFOVF during a write doesn't trigger a callback,

 

DMA does seem to be the way to go.  Haven't made the leap yet.  Maybe on the roadmap for future major release of product.

 

Mark

 

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

I have been able to work on the error handling for BUFOVF, so it should help with the double buffering.

 

As someone is, helpfully, mirroring ASF releases on GitHub, I have committed my changes there,

https://github.com/bewster/microchip-asf/commit/f31c55bb91bea96ef651d5f25b9aa3c02a4b9fa0