SPI_MODE0 appears to not be handled correctly.

[rfestag]

Hardware:

Board: Adafruit ESP32 Feather
Core Installation version: Git master
IDE name: Arduino IDE
Flash Frequency: 80Mhz
PSRAM enabled: No idea?
Upload Speed: 115200
Computer OS: Manjaro (Arch derivative)

Description:

I believe SPI modes might not be handled properly in this library. This is related to #2542, where I found that changing the hard-coded SPI_MODE from SPI_MODE0 to SPI_MODE1 resolved issues talking to the SPI flash on board a Teensy Prop Shield using the SerialFlash library (https://github.com/PaulStoffregen/SerialFlash).

I originally closed that ticket because it seemed like something the SerialFlash library could be modified to allow us to override (i.e., allow users to set a different SPI mode). However the maintainer of that library said the SPI modes should be standard, and this particular device expects to be communicated with via SPI_MODE0. This is the ticket I submitted there: PaulStoffregen/SerialFlash#57.

I'm not sure how to proceed with a solution. I did find a ticket from about a year ago where SPI mode settings were changed (although none appear to be related to SPI_MODE0): #1094. Perhaps that change fixed an issue that existed somewhere else in the handling of SPI that worked for their device, but broke others?

Sketch:

#include <SerialFlash.h>
#include <SPI.h>

#define MEM_CS 12

//These are copied from SerialFlash for illustration. They 
#define DEFAULT_MAXFILES      600
#define DEFAULT_STRINGS_SIZE  25560

static uint32_t check_signature(void)
{
        uint32_t sig[2];
        uint32_t sig2[2];

        SerialFlash.read(0, sig, 8);
        Serial.printf("sig: %08X %08X\n", sig[0], sig[1]);
        if (sig[0] == 0xFA96554C) return sig[1];
        if (sig[0] == 0xFFFFFFFF) {
                sig[0] = 0xFA96554C;
                sig[1] = ((uint32_t)(DEFAULT_STRINGS_SIZE/4) << 16) | DEFAULT_MAXFILES;
                Serial.printf("Writing sig: %08X %08X\n", sig[0], sig[1]);
                SerialFlash.write(0, sig, 8);
                while (!SerialFlash.ready()) ; // TODO: timeout
                SerialFlash.read(0, sig2, 8);
                Serial.printf("Reading sig2: %08X %08X\n", sig2[0], sig2[1]);
                if (sig2[0] == 0xFA96554C) return sig2[1];
        }
        return 0;
}
void setup() {
  Serial.begin(115200);
  Serial.println();

  //Setup Serial Flash
  if (!SerialFlash.begin(MEM_CS)) {
    Serial.println("Unable to access SPI Flash chip");
  }
  
  //These writes actually work. We do it to ensure the first part of
  //the flash storage is 0xFFFFFFFF, forcing it to try to write the magic number
  SerialFlash.eraseAll(); 
  unsigned long dotMillis = millis();
  unsigned char dotcount = 0;
  while (SerialFlash.ready() == false) {
    if (millis() - dotMillis > 1000) {
      dotMillis = dotMillis + 1000;
      Serial.print(".");
      dotcount = dotcount + 1;
      if (dotcount >= 60) {
        Serial.println();
        dotcount = 0;
      }
    }
  }
  //We call the function SerialFlash uses internally to verify
  //that the state of the storage is valid (i.e., it has the magic number)
  check_signature();
}

void loop() {}

Debug Messages:

...................sig: FFFFFFFF FFFFFFFF
Writing sig: FA96554C 18F60258
Reading sig2: 7DCB2A26 0C7B012C

[rfestag]

Update: It looks like the real problem was the SPISettings for the library I'm using setting the max speed high (50Mhz). While the ESP32 documentation talks about max speeds of 80Mhz, that only seems to apply to CS0 (Pin 15) if I am understanding correctly. I am not sure there is a way to remap the IOMUX for the CS pin to allow me to take advantage of the full speed. As a result, I need to use a max speed of no more than 26Mhz, which requires a change in the SerialFlash library.

More information is in this issue on SerialFlash: PaulStoffregen/SerialFlash#57

Is it actually possible to remap the CS0 IOMUX pin to whatever I'm actually using for this external flash? Or would that cause issues for the internal SPI flash?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This stale issue has been automatically closed. Thank you for your contributions.