-
Notifications
You must be signed in to change notification settings - Fork 7.6k
Issues writing to SPI Flash via SerialFlash library on Teensy Prop Shield #2542
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
@rfestag look through the library code and see if it set the SPI_MODE. It could be a difference in default modes between the Library and ESP32. Chuck. |
@stickbreaker: It looks like it does so here: #define SPICONFIG SPISettings(50000000, MSBFIRST, SPI_MODE0) Does that seem appropriate for the ESP32? If not, what makes sense? |
@rfestag try changing the SPI_MODE0, to mode 2 |
Using |
it's not an SPI mode problem, i wrote in |
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 am trying to use the Teensy Prop Shield to store files in it's on-board SPI flash (W25Q64FV) using the SerialFlash library (https://github.com/PaulStoffregen/SerialFlash). As far as I can tell, it seems like the least significant bit of the data being written is not being sent to the device by the SerialFlash library. I know lots of people are using this library successfully on other platforms, which makes me think there is an issue with the SPI implementation here. I know in the past there have been issues with I2C (which, coincidentally, I also ran into with this shield, but specifically were related to the motion sensors on board and were resolved a year or so ago).
This library expects a certain magic word (0xFA96554C) to be the first 16 bits of the flash memory. Any attempt to create a file without this (or 0xFFFFFFFF) will cause the write to fail. If it detects 0xFFFFFFFF, it assumes the storage has been wiped, and it will write the magic word, followed by some size information.
In my tests, the first 32 bits of memory should be:
0xFA96554C
0x18F60258
However, upon reading the data immediately after writing, the following is actually written:
0x7DCB2A26
0x0C7B012C
When I compare the binary, the actual written value appears to be bit-shifted:
Expected:
FA 96 - 11111010 10010110
Actual:
7D CB - 01111101 11001011
Fix: left-shift a 0 into each byte
11111010 10010110
Expected:
55 4C - 01010101 01001100
Actual:
02 58 - 00101010 00100110
Fix: left 1 into higher byte, 0 into lower byte
01010101 01001100
This seems to imply that the transfer is somehow missing the the least significant bit on each byte. What is odd is that this doesn't seem to be pervasive (some writes are fine, such as when transferring the command to bulk erase the flash). It seems to be a problem when iteratively writing bytes.
Sketch:
Debug Messages:
The text was updated successfully, but these errors were encountered: