SAM D20 Xplained Pro SPI Slave Callback Example Standby Current

1 post / 0 new
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am currently working on a project with a SAM D20 and am running into a current consumption issue related to the SPI port. We are attempting to use the SPI port configured as a slave with callbacks. The OSC8M is configured to run in standby and on demand. The SPI peripheral is also configured to run in standby. The MCU is then placed into standby mode.


According to the datasheet, it appears the undivided OSC8M oscillator pulls about 70 uA (section 33.12.6) and the SPI peripheral pulls about 48 uA (section 33.7). Adding this to the typical CPU standby current of about 3 uA (section 33.6) gives us a rough current draw estimation of about 121 uA. An additional 20 uA is consumed on the dev board due to die revision C Errata 13140. Also, an additional 70 uA is allocated to keep the VREG is high current mode at all times to eliminate as a source of issues. This leads to a total estimated current draw of 211 uA.


However, using the SAM D20 Xplained Pro dev board (die revision C), along with the attached Atmel Studio project (based on ASF SPI_QUICK_START_SLAVE_CALLBACK example project), we are seeing currents higher than expected when waiting for a SPI slave callback. I have disconnected the SPI master and have applied pull-ups on the SPI slave channel to prevent floating inputs and have masked the unused peripheral clocks according to app note AT04188.


The CPU standby current when no SPI job is pending is about 93 uA.

spi_read_buffer_job is pulling about 93 uA. It appears that there is no demand for OSC8M while in this mode.

spi_write_buffer_job is pulling about 654 uA.

spi_transceive_buffer_job is pulling about 654 uA.


I have attached the project. We have a target of <250 uA for this portion of the project. Is there an explanation for this discrepancy? Are the peripheral or clocks being configured incorrectly? Am I misinterpreting the datasheet?