sparkfun / Arduino_Boards

Board definitions for SparkFun-manufactured AVR, ARM, and ESP-based Arduino boards.
267 stars 123 forks source link

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

Open interfect opened 3 years ago

interfect commented 3 years ago

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:

https://github.com/sparkfun/Arduino_Boards/blob/682926ef72078d7939c12ea886f20e48cd901cd3/sparkfun/samd/variants/SparkFun_SAMD51_Thing_Plus/variant.h#L148-L158

And 91492c20c0e7b8c8c0afdc28985e98389f87aa80 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 91492c20c0e7b8c8c0afdc28985e98389f87aa80 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 91492c20c0e7b8c8c0afdc28985e98389f87aa80 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 commented 3 years ago

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?