S29GL256S not writing to flash

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
zveber2000
Level 1
Level 1
5 sign-ins First reply posted First question asked

Hi all,

we have an S29GL256S10DHV020 connected to an STMH745 wired as in the attached pictures

NOR_Flash.png

STM32H745.png

The difference from the schematic is that we rewired the WE to PD5 of the MCU, and connected a pullpup resistor to the RY/BY line.

When HAL_NOR_Read_ID(&hnor1, &norID); is called I get data that I expect, and memory browser shows as in the attached screenshot.

2021-05-26 09_24_54-Window.png

The issue that i am facing that i cannot write into the flash, when i read back i get only 0xFFs.

I am attaching some waveforms (tek00-05.png) that i have collected each time when functions are executed.

HAL_NOR_Read_ID(&hnor1, &norID);

HAL_NOR_ReturnToReadMode(&hnor1);

HAL_NOR_Erase_Chip(&hnor1, NOR_BANK_ADDR);

HAL_NOR_Erase_Block(&hnor1, WRITE_READ_ADDR, NOR_BANK_ADDR);

uint16_t var=0x1234;
HAL_NOR_Program(&hnor1, (uint32_t *)(NOR_BANK_ADDR + WRITE_READ_ADDR), &var);

HAL_NOR_ReadBuffer(&hnor1, NOR_BANK_ADDR + WRITE_READ_ADDR, &aRxBuffer[0], 1);

 

Do you observe anything unusual, what could be the root cause that data is not written?

0 Likes
8 Replies
Apurva_S
Moderator
Moderator
Moderator
100 likes received 500 replies posted 250 solutions authored

Hi @zveber2000 

Are you using the low level driver for parallel NOR flash by Infineon(Cypress) or are these functions part of some other driver?

0 Likes
zveber2000
Level 1
Level 1
5 sign-ins First reply posted First question asked

Hi AS_36, thanks for the reply

These functions are part of the stm32h7xx_hal_nor.c belonging to the STM32Cube_FW_H7_V1.8.0

https://www.st.com/en/embedded-software/stm32cubeh7.html 

I was trying to use the Lld_s29gl256s.c, without success. I have here some observations:

lld_GetDeviceId - returned non 0xFF, only in case i was stepping trhough the function with the debugger.

lld_ChipEraseCmd - RY/BY line went low at last instruction, only in case i was stepping through the function. 

nevertheless, writing to flash did not succeed.

 

We used this low level driver fine, with RM48 and TMS570 MCUs from TI

0 Likes
zveber2000
Level 1
Level 1
5 sign-ins First reply posted First question asked

Status update:

lld_WriteBufferProgramOp and lld_ProgramOp both return DEV_SECTOR_LOCK, although before calling them i erased the chip. called lld_ChipEraseCmd , and confirmed that RY/BY line was low for about 1 minute.

 

Writing works now starting from the second sector.

0 Likes
Apurva_S
Moderator
Moderator
Moderator
100 likes received 500 replies posted 250 solutions authored

Hi,

Writing works now starting from the second sector - I am not clear about this. What happens if you try to write to the first sector?

You can go over our low level driver for parallel NOR flash to check if your driver is following the same sequence of commands - https://www.cypress.com/documentation/software-and-drivers/low-level-driver-nor-flash?source=search&... or you should contact ST for specific return value related queries.

Please do let me know if you have any questions related to the flash device or our LLD.

Regards.

0 Likes
zveber2000
Level 1
Level 1
5 sign-ins First reply posted First question asked

If i attempt to write to the first sector, by using functions lld_WriteBufferProgramOp and lld_ProgramOp, being part of the low level driver, they return  DEV_SECTOR_LOCK.

0 Likes
Apurva_S
Moderator
Moderator
Moderator
100 likes received 500 replies posted 250 solutions authored

Hi @zveber2000 

Have you implemented any kind of protection for the first sector? The LLD returns DEV_SECTOR_LOCK if the status register bit 1 is found to be set, which indicates that a program/erase operation failed because the particular sector was locked. Please see table 5.2 of the datasheet.

I would also like to point out that when a chip erase operation is performed, the locked sectors are skipped and the status register erase status bit and sector lock bit are NOT set to 1. Please see section "5.4.4.1 Chip Erase" of the datasheet.

AS_36_0-1622623895253.png

Regards.

 

0 Likes
zveber2000
Level 1
Level 1
5 sign-ins First reply posted First question asked

Hi AS_36,

I did not implement any kind of protection mechanism, the PCB is just recently received from our PCB manufacturer.

Regards.

0 Likes
Apurva_S
Moderator
Moderator
Moderator
100 likes received 500 replies posted 250 solutions authored

Hi @zveber2000 

I understand that the PCB and flash parts are new and it is not intentional to implement protection scheme. However, could you please still read the PPB and DYB bits for the first sector just to confirm that it is not protected unintentionally?

As you can see from the driver, it returns DEV_SECTOR_LOCK status only when bit 1 of the status register is found to be set, which is the sector lock status bit indicating the failure of the most recent program or erase operation because the sector was locked.

You can use the lld_PpbStatusReadCmd and lld_DybReadCmd API from the driver for reading the PPB and DYB bits respectively.

Regards.

0 Likes