- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi all,
we have an S29GL256S10DHV020 connected to an STMH745 wired as in the attached pictures
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.
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Regards.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi AS_36,
I did not implement any kind of protection mechanism, the PCB is just recently received from our PCB manufacturer.
Regards.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.