Nor Flash Forum Discussions

Last year we switched to using the Cypress S29GL01GS10FHI02 Flash. We are currently having a problem on all these systems with erasing sector zero with our custom MTD driver running on a PPC 440EP. All other sectors erase and program fine using that driver. Sector zero can be erased and programed under U-boot. If U-boot is used to boot the system, then our custom MTD driver can erase and program sector 0 correctly.

When it fails to erase, the flash reports a status of A2 after ~10us, which according to document #001-98285 Rev R means Erase failure because sector is locked. However, the sector is not locked. It can be programmed with U-boot and the MTD driver in the same way after a U-boot boot. Also, reading the lock state (both volatile or not) of that sector returns 1 (Unprotected). Trying to unprotect the sector has no effect. The memory map appears to be correct as I can read the sector correctly from the MTD driver and all commands issued to the flash at that base address work (except the erase of sector zero). The bus speed is the same under U-boot or the factory boot (125ns). Nothing in the documentation hints at sector zero being special. The code to erase is very simple; the Sector address = base address in this case.

#define AMD_CMD_ERASE_START                                      0x0080

#define AMD_CMD_ERASE_SECTOR                                   0x0030

#define AMD_CMD_UNLOCK_START                                   0x00AA

#define AMD_CMD_UNLOCK_ACK                                       0x0055

#define AMD_ADDR_START                                                  0x0555

#define AMD_ADDR_ACK                                                       0x02AA

volatile u_short* base = (u_short*)( s->vaddr );

volatile u_short* addr = flash_make_addr (s, blkno);

              *(base + AMD_ADDR_START ) = AMD_CMD_UNLOCK_START;

              SYNC;

              *( base + AMD_ADDR_ACK ) = AMD_CMD_UNLOCK_ACK;

              SYNC;

              *(base + AMD_ADDR_START ) = AMD_CMD_ERASE_START;

              SYNC;

              *(base + AMD_ADDR_START ) = AMD_CMD_UNLOCK_START;

              SYNC;

              *( base + AMD_ADDR_ACK ) = AMD_CMD_UNLOCK_ACK;

              SYNC;

              *( addr ) = AMD_CMD_ERASE_SECTOR;

              SYNC;

Please help,

Frederic

I have a question regarding page programming when the data, sent along with PP command, exceeds the buffer size.

Here is the text from Cypress specification:

If more data is sent to the device than the space between the starting address and the page aligned end boundary, the data loading

sequence will wrap from the last byte in the page to the zero byte location of the same page and begin overwriting any data

in the page. The last page worth of data is programmed in the page. This is a result of the device being equipped

with a page program buffer that is only page size in length. If less than a page of data is sent to the device, these data bytes will be

programmed in sequence, starting at the provided address within the page, without having any affect on the other bytes of the same

page.

Let’s assume:

The buffer size is 256 bytes

Address is 0x0

Data received are 258 bytes (byte 0 is 0x00,     byte 1 is 0x01,      byte 2 is 0x02, ……..           byte 255 is 0xFF,       byte 256 is 0xAA,        byte 257 is 0xBB)

After the receiving 256 bytes, the page buffer will contain: 0x00, 0x01, 0x02, ………, 0xFF

The new data (exceeding 256 bytes will overwrite the first byte): so the page buffer will contain at the end: 0xAA, 0xBB, 0x02, ………. 0xFF.

Now what data do you expect to be written to the memory?

Option A:        Last 256 received bytes will be written to memory starting from the given program address which is 0x0 in this example

@address 0x0  à 0x02

@address 0x1  à 0x03

@address 0x2  à 0x04

…..

@address 0xFE  à 0xAA

@address0xFF à 0xBB

Option B:  The page program buffer is written to the corresponding memory’s page (page 0 in this example)

@address 0x0  à 0xAA

@address 0x1  à 0xBB

@address 0x2  à 0x02

…..

@address 0xFE  à 0xFE

@address0xFF à 0xFF

Thanks,

Mona

I have tried to solve the problem that the S25FL256SAGNFI001(WSON, QUAR SPI FLASH) IS NOT NORMAL WORKING.

The driver code is normal with S25FL256SAGMFI01(16 SSOP) on old PCB version.

I changed the chipset to the  S25FL256SAGNFI001(8 WSON) for new PCB but it has not worked with the same driver code.

According to the data sheet, there seems not to be different between two chipset except their type, number of pin and package size.

We tried to  jumper by wire from the pads on the new PCB to the 16 SSOP chipset pins. It is normal.

so, the patterns of the new PCB appear to be normal.

The problem is verification error.

I neet to help....

Using chip S25FL256SAGMFI003.  Works great from factory.  I can erase sectors (0xDC), program (0x12), read (0x13), etc.  As soon as I use WRR to set QUAD bit to 1 in configuration register (setting/leaving everything else at 0), sector or bulk erase commands fail to set memory to all 1's (memory content remains unchanged).  I can still use program array commands (0x12) to effectively flip bits from 1 to 0, but cannot get erase (including bulk erase) to have any effect even though they worked fine before QUAD bit was set.  I read status and config registers, which return 0x02 and 0x02 respectively (which I think is correct).  I also tried adding software reset command before trying to erase sectors, etc.  I'm out of ideas.  Anyone have any suggestions?

Best regards,

David

Hi,

Customer ask us to programming SPI flash(S25FL064LABNFI030) on production line and recommend using J-Link.

Could you recommend J-Link kit number？

J-Link LITE Cortex-M | SEGGER - The Embedded Experts

or others?

Please  advise  us.

Regard,

Kevin

I have a problem understanding the S70FL01GS I/O voltage capabilities.

The data sheet front page indicates that the part supports 1.8V I/O:

 Core Supply Voltage: 2.7V to 3.6V

 I/O Supply Voltage: 1.65V to 3.6V

But the VIO pin description in the data sheet says that VIO is not supported:

VIO Supply Versatile I/O Power Supply. Note: VIO is not supported in the S70FL01GS device. Refer to Section 7. for more details.

7. Versatile I/O Power Supply (VIO) Note that the Versatile I/O (VIO) power supply (pin 14 on the 16-pin SO package and ball E4 on the 5x5 BGA package) is not supported, and pin 14 and ball E4 are RFU (Reserved for Future Use) in the standard configuration of the S70FL01GS device. Contact your local sales office to confirm availability with the VIO feature enabled.

Is the device capable of supporting 1.8V I/O?

Cypress App note AN98507 also indicates the part supports 1.8V I/O.  Table 3 shows that the S70FL01GS is suitable for use with the Zynq 7000 series at 3.3V and 1.8V I/O.

The part was used on a Xilinx evaluation board with 1.8V I/O.

We have been using the part with a Zynq 7000 at 1.8V I/O successfully, but now a new batch of boards does not seem to be working.  Has something about the part changed?  The only difference is that we are now using the Automotive temperature range parts.  We are unable to program (write) the parts now.

Is there an alternate or variant of the part that would work?

I want to replace FLASH IC from N25Q128A13ESE40G to S25FL127SABMFV101.

Are there any points to change with Soft ware?

Hi,

I plan to use S25FL256S (S25FL256SAGMFIR01) in my design for 1.8V VIO operation. Attached is the schematics.

I have 3 supplies

1. B_1V8_SF - 1.8V for serial flash (generated for sequencing)
2. B_3V3_D - 3.3V System Supply
3. B_1V8_D - 1.8 V System Supply

In system board power sequencing is such a way that B_1V8_D --> B_3V3_D --> B_1V8_SF.

in order to meet the sequencing need for i generate B_1V8_SF from B_3V3_D.

pls review my schematics

My concerns are

1. Which pull up (HOLD & WP) rail I should use B_1V8_D or B_1V8_SF?? my concern is since B_1V8_D come first will it raise the voltage level of VIO rail via input pins??

2. IF I need to cull up CS as suggested in data sheet which rail should I use.

Please suggest