Hi, first of all congrats on the great work! I've tested your libraries using reading tests and the results were very good.
However, do you have any idea why the write test wouldn't work on a Cypress S25FL164K ?

Thanks for the tip!
I think that I might have found out what's the problem: register 1 and 2 seem to not be set up properly.
But why? I will take a closer look into this and come up with an update when I figure it out.

8.1.2 Write Enable (06h)
The Write Enable command (Figure 35) sets the Write Enable Latch (WEL) bit in the Status Register to a 1. The WEL bit must be set
prior to every Page Program, Sector Erase, Block Erase, Chip Erase, Write Status Registers and Erase / Program Security
Registers command. The Write Enable command is entered by driving CS# low, shifting the instruction code “06h” into the Data
Input (SI) pin on the rising edge of SCK, and then driving CS# high.

I doubt void ExtFlash::cmd(uint8_t cmd) methond is the one causing the problem. Instead, I would assume there's something wrong with either spi_transaction_ext_t *ExtFlash::cmd_prolog() or void ExtFlash::cmd_epilog(spi_transaction_ext_t *t), but these methods seem to work fine when it comes to reading. Any idea on the problem?

The results are the same as in the previous posts
I've noticed a difference while mapping the commands for the particular Cypress flash that I'm using: status register 1 and status register 2 are both written using the same command 0x01h, while the Winbonds flash that you've designed the library for use 0x01h for the first status register and 0x31h for the 2'nd. I don't see why, but could this be the problem?
I've mapped them in the following way (as posted in the first post):

And yes, it would matter in the bigger picture. The is an example of why I made nearly all of the methods virtual. There "seems" to be a general flash "standard", but there seems to be slight differences here an there that must be handled by chip specific code.

But in your case, I don't think it matters at this point since the only thing you'd be using reg2 for is the QE bit and you're working with dual. And write_status_register1 isn't being called from anywhere.

That still doesn't explain why the "write enable" command isn't setting the WEL bit in SR1.

For the heck of it, can you add a call to "vTaskDelay(1000);" after the cmd() call in write_enable(). Just trying to see if there's some sort of timing issue.

Also, have you tried just plain old non-dual mode? I really don't think it'd matter, but it "might" tell us "something".

I also don't see why the write_enable() method doesn't set the WEL bit in SR1.
I've attached the modified library that I'm using if you want to take a look into this. I think I've spent more than 24hrs total looking for the problem; still haven't found it. As mentioned earlier reading tests work like a charm, the writing is the culprit.

It all "looks" good. I'm really starting to wonder if reading is actually working. Even though the esp32 SPI transactions complete normally, that's not a guarantee that they really did work since there's no success/failure response from the chip.

The only thing I can think to check is the wiring and pin assignments, though I'm sure they're okay since the CMD_READ_SFDP or CMD_READ_JEDEC_ID must have worked to determine the sector size and chip capacity.

I would buy a chip from mouser to help debug, but I don't have access to my soldering stuff right now (I solder in the garage and it's about 30F out there).

Who is online

About Us

Espressif Systems is a fabless semiconductor company providing cutting-edge low power WiFi SoCs and wireless solutions for wireless communications and Internet of Things applications. ESP8266EX and ESP32 are some of our products.