SPI1 is not able to get a response from the Adesto AT25SF041 flash chip on the SAMD51 Thing Plus

[interfect]

I recently ordered a SAMD51 Thing Plus, and I wanted to try and use the on-board SPI flash memory chip (an Adesto AT25SF041 on my board).

It looks like the variant sets up the macros that let the SPI library define an SPI1 that will talk to the flash chip:

Arduino_Boards/sparkfun/samd/variants/SparkFun_SAMD51_Thing_Plus/variant.h

Lines 148 to 158 in 682926e

	#define PIN_SPI1_MISO (35u)
	#define PIN_SPI1_MOSI (36u)
	#define PIN_SPI1_SCK (33u)
	#define PERIPH_SPI1 sercom0
	#define PAD_SPI1_TX SPI_PAD_0_SCK_1
	#define PAD_SPI1_RX SERCOM_RX_PAD_3
	static const uint8_t FLASH_SS = 34 ; // SERCOM0 last PAD is present on 34 but HW SS isn't used. Set here only for reference.
	static const uint8_t FLASH_MOSI = PIN_SPI1_MOSI ;
	static const uint8_t FLASH_MISO = PIN_SPI1_MISO ;
	static const uint8_t FLASH_SCK = PIN_SPI1_SCK ;

And 91492c2 by @AndyEngland521 made sure to configure the relevant pins to actually expose sercom0 (which backs SPI1) to the physical pins on the MCU.

But I'm struggling to verify that 91492c2 actually worked to enable communication with the flash chip. Both with the SPIMemory library (which supports the AT25SF041) aimed at FLASH_SS and SPI1, and with just using SPI1 myself to send the 0x9F "Read Manufacturer and Device ID" command from the data sheet, I'm not getting any indication that the chip is hearing me. I see all 0s where I should be seeing the device ID coming down the line.

My simplest test sketch is here:

#include <SPI.h>

// Since the SAMD51 variant configures the SPI library by setting
// SPI_INTERFACES_COUNT and associated macros, we get the board
// flash chip SPI interface already in an object named SPI1.
// variant.h also defines FLASH_SS for selecting it.

// We have an Adesto AT25SF041 SPI flash chip
// https://www.adestotech.com/wp-content/uploads/DS-AT25SF041_044bak.pdf
// It can go at up to 104 MHz and has a chip select on FLASH_SS that must be low.
// Although it can only take 50 MHz for some commands.
// It holds 4 megabits, or 512Kb.
// It will take SPI modes 0 or 3, and communicates MSB-first.
// You send it 8-bit opcodes, with optional arguments, and then it sends back stuff.

// Flash is hooked to pads 17, 18, 19, 20 as MOSI,SCK,CS,MISO
// Which are also port A bits 8, 9, 10, 11
// Which are also Arduino pin numbers 36, 33, 34, 35
// MOSI is on pad 0 of sercom 0, with SCK on pad 1. And MISO is on sercom 0 pad 3. And !CS is on sercom 0 pad 3.
// This is also sercom 2, but with MOSI on pad 1 and SCK on pad 0, but that's not an allowed way to use a sercom.
// The variant helpfully sets this all up as SPI1.
// In v1.6.2 of the board definition the pins come configured as PIO_COM (function G in the datasheet, QSPI)
// and need to be PIO_SERCOM (function C, sercom0).
// But this is fixed in the current version. 

// the setup function runs once when you press reset or power the board
void setup() {
  Serial.begin(9600);
  pinMode(FLASH_SS, OUTPUT);
  // Adding these doesn't help
  //pinMode(FLASH_MOSI, OUTPUT);
  //pinMode(FLASH_MISO, INPUT);
  //pinMode(FLASH_SCK, OUTPUT);
}

// the loop function runs over and over again forever
void loop() {
  delay(3000);
  SPI1.beginTransaction(SPISettings(104000000, MSBFIRST, SPI_MODE0));
  digitalWrite(FLASH_SS, LOW);
  SPI1.transfer(0x9F);
  delay(100);
  int b1 = SPI1.transfer(0);
  int b2 = SPI1.transfer(0);
  int b3 = SPI1.transfer(0);
  digitalWrite(FLASH_SS, HIGH);
  SPI1.endTransaction();
  Serial.print("0x");
  Serial.println(b1, HEX);
  Serial.print("0x");
  Serial.println(b2, HEX);
  Serial.print("0x");
  Serial.println(b3, HEX);
}

@AndyEngland521, can you share the test sketch you used to verify that 91492c2 fixed communication with the flash chip? Or is there any other known good example code that talks to that chip?

I haven't been able to find any examples that have ever gotten the onboard flash chip working, only this person in August asking about it on the SparkFun forums and getting nothing when referred to the Arduino forums.

I suspect that, despite the reconfiguration of the pin definitions, the flash chip on the board still may not actually be accessible.

[interfect]

I've found this forum post claiming that the SPI flash is used by the bootloader for something.

If so, why bother to expose SPI1 and the FLASH_* macros to Arduino sketches, and assign Arduino pin numbers? And even if it is holding Important Bootloader Things, shouldn't I still at least be able to get it to report back its ID?