Nor Flash Forum Discussions
Please confirm the assembly site of S29GL256S90FHI020.
Hi Folks,
I'm very new to memory technology,
I'm working on imx8 platform(yocto and kernel build 4.14) and and have attached S25FS512.
I'm able to find id of this nor flash into ./drivers/mtd/spi/spi_flash_ids.c. now in my config CONFIG_SPI_FLASH_STMICRO is enabled by default but i might need to enable
CONFIG_SPI_FLASH_SPANSION(?!)
So is there any documentation available on DTS changes and u-boot/kernel changes to get a starter.
Please let me know if more information is needed from my end.
Any leads would greatly appreciable.
Thanks & Regards,
Rutvij
Hello,
I am using the command (21h) to sector erase in QSPI mode.
Trying to erase area 0x10000 - 0x10FFF (4k), but this is not possible,
the previous sectors for example (0x0000 - 7FFFh) is possible to erase using the above command.
Could you please let me know as to why I am not able to erase this sector?
Thanks and Regards,
Edwin
Show LessHello,
I am using the S25FS512SDSBHV213 in serial SPI mode. Quad is not available on the nrf52832 processor. The only commands that seem to have effect are volatile ones, all non-volatile commands appear to fail silently. I only have the one custom PCB for another few weeks, is there any other tests I can run to see if it is just a bad IC, or if it is my firmware?
Code Run |
---|
//Set 4 byte mode static uint8_t four_byte_mode[] = {0xB7}; static uint8_t four_byte_mode_len = 1; ////Read from Any register static uint8_t rdar_addr[] = {0x65, 0x00, 0x00, 0x00, 0x00 }; //Reads from any register static uint8_t rdar_addr_len = 5; static uint8_t rdar[64]; static uint8_t rdar_len = 5+1; //write length plus actual register ////Write to Config Register 2 Non-Volatile static uint8_t cr2nv[] = {0x71, 0x00, 0x00, 0x00, 0x03, 0x88}; //writes to CR2NV , bit7=4-byte addressing, 6=QSPI, 5=IO3Reset,4=RFU, 3-0 = Read Latency static uint8_t cr2nv_len = 6; //Write Enable Command static uint8_t write_en_cmd[] = {0x06}; //addr 06 static uint8_t write_en_cmd_len = 1; static void memory_read_register(uint32_t address, char * str, uint8_t len) { if(memory_wait_until_ready() == false) { NRF_LOG_ERROR("Flash timed out before we could erase everything"); NRF_LOG_FLUSH(); } set_command_address(rdar_addr,address); spi_read(FLASH_SSEL_PIN,rdar_addr,rdar_addr_len,rdar,len); NRF_LOG_RAW_INFO("%s ",str); uint8_t i; for(i=0; i < len; i++) NRF_LOG_RAW_INFO("0x%02x ",rdar); NRF_LOG_RAW_INFO("\r\n"); NRF_LOG_FLUSH(); } void memory_init (void) { ret_code_t err_code; uint8_t i; for(i=0; i < 4; i++) who_am_i = 0; //read the information about the flash to make sure it is the correct one spi_read(FLASH_SSEL_PIN,who_am_i_addr,who_am_i_addr_len, who_am_i, who_am_i_len); NRF_LOG_DEBUG("Indentification info should match 0x01,0x02,0x20 : 0x%02x,0x%02x,0x%02x ", who_am_i[1], who_am_i[2], who_am_i[3]); //Set ourselves in 4-byte addressing mode spi_write(FLASH_SSEL_PIN,write_en_cmd, write_en_cmd_len); spi_write(FLASH_SSEL_PIN,four_byte_mode, four_byte_mode_len); nrf_delay_ms(100); //Permanently set ourselves into 4 byte mode spi_write(FLASH_SSEL_PIN,write_en_cmd, write_en_cmd_len); spi_write(FLASH_SSEL_PIN,cr2nv, cr2nv_len); nrf_delay_ms(100); //flash memory timer err_code = app_timer_create(&flash_erase_timer_id, APP_TIMER_MODE_SINGLE_SHOT, flash_erase_timeout_handler); APP_ERROR_CHECK(err_code); //read from our status registers spi_read(FLASH_SSEL_PIN,sr1v_addr,sr1v_addr_len,sr1v,sr1v_len); NRF_LOG_INFO("SR1: %d",sr1v[2]); spi_read(FLASH_SSEL_PIN,sr2v_addr,sr2v_addr_len,sr1v,sr1v_len); NRF_LOG_INFO("SR2: %d",sr1v[2]); spi_read(FLASH_SSEL_PIN,cr1v_addr,sr1v_addr_len,sr1v,sr1v_len); NRF_LOG_INFO("CR1: %d",sr1v[2]); memory_read_register(0x00800000, "SR1:", 8); memory_read_register(2, "CR1NV:", 8); memory_read_register(3, "CR2NV:", 8); memory_read_register(4, "CR3NV:", 8); memory_read_register(5, "CR4NV:", 8); memory_read_register(0x00800002, "CR1:", 8); memory_read_register(0x00800003, "CR2:", 8); memory_read_register(0x00800004, "CR3:", 8); memory_read_register(0x00800005, "CR4:", 8); memory_read_register(0x00800040, "PPBL:", 8); spi_write(FLASH_SSEL_PIN,write_en_cmd, write_en_cmd_len); memory_read_register(0x00800000, "SR1:", 8); memory_read_ppbr(0, "PPBR:", 16); NRF_LOG_FLUSH(); FLAG_FLASH_FINISHED_ERASING = 0; head_pointer = 0; tail_pointer = 0; } |
Results |
---|
<debug> app: Indentification info should match 0x01,0x02,0x20 : 0x01,0x02,0x20 <info> app: SR1: 0 <info> app: SR2: 0 <info> app: CR1: 0 SR1: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 CR1NV: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 CR2NV: 0x00 0x00 0x00 0x00 0x00 0x00 0x08 0x08 CR3NV: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 CR4NV: 0x00 0x00 0x00 0x00 0x00 0x00 0x10 0x10 CR1: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 CR2: 0x00 0x00 0x00 0x00 0x00 0x00 0x88 0x88 CR3: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 CR4: 0x00 0x00 0x00 0x00 0x00 0x00 0x10 0x10 PPBL: 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x01 SR1: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 PPBR: 0x00 0x00 0x00 0x00 0x00 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF |
Hi all
I'm currently using a S25FL164K SPI NOR flash in one of our designs. I'd like to program a few bytes on different offsets of a single page at different times. My question is if these multiple writes to the same page cause the flash to wear out. Or is it only the erase operation which causes wear out. The data sheet specifies only the erases per sector (which are at 100000) but not the writes per sectors.
Best regards
Show LessGreetings.
I'm using PSoC 5LP in my project along with S25FL127SABMFI101 SPI flash for logging data.
I have done all the steps necessary to include the library emFile. But I'm still not able to format the flash, create a directory and access it.
Its returning 'Failed'. Please help.
I recently started learning PSoC 5LP. Any help is appreciated.
Thanks and Regards
Vinay
Show LessHi,
We are currently using this part (S29GL128P11FFI013) in of our products. According to document 001-11743 (Rev. K) this part is about to go obsolete during 2019. Since we are currently doing a revision upgrade on our product we would like to swap this part out. Does Cypress have a drop in replacement part for S29GL128P11FFI013? Or maybe a similar part with the same package (LAA064) but with larger capacity that we can use.
Br
/Martin
Show LessHello,
I know this part has been obsoleted long time ago. However, we are still using it on a product as the main program memory.
As is (or was) common with these parts, code is executed in place, i.e. directly from the Flash itself.
We never write to the flash during normal operation, although we support firmware update on the field.
We were reported cases of memory corruption (which is detected by computing a CRC code), so we decided to investigate.
We analyzed two samples from the field and found that both of them had failed because of a single bit corruption (not the same bit and not in the same (H or L) data byte in the two cases, but just one bit out of the full 8 Mbits of the part in both cases); in both cases, corruption consisted into turning value 1 bits into 0 value.
Also, corruption was reversible, i.e. reprogramming the device fixed it.
We believe it is nearly impossible for this to have occurred following an out-of-control software jump to the programming routines used for Firmware Update, as we are sure a much more extensive corruption would occur if that ever happened.
We then read about the "Read Disturb" issue which however mostly affects NAND flashes, not NOR ones; we found a few references mentioning Read Disturb for NOR flash as well, but they were unclear whether this could occur on the very old process used for this part, or only on today's much more advanced processes. After all, if this could happen on this kind of device, would designs rely on in place code execution without taking any measure to increase robustness?
Other mechanism we are thinking about for the issue to occur is some spurious and short reset pulse which may be generated by the power supervisor chip e.g. following a brownout. Could this leed to the above described type of corruption, especially if such pulse does not also reset the processor?
And would it be more likely for such corruption to happen at (or near) locations the processor is currently reading (fetching code) at the moment the spurious pulse occurs? Asking this because in both cases corruption occurred at locations occupied by the code of the small "Idle" thread of the microkernel, which is the most frequently executed code (this would also be consistent with the Read Disturb theory, though).
Show Less