Hello ST Community,
I’m currently working on a routed circuit where I’m interfacing an STM32H735IGT6 microcontroller with an external NOR flash memory (MT25QL512ABB1EW9-0SIT). While most operations seem to work as expected, I’m encountering an issue with programming a page, and I’d appreciate your insights.
System Details:
- MCU: STM32H735IGT6
- External NOR Flash: MT25QL512ABB1EW9-0SIT
- Driver Files: Using MT25QL512ABB.c for flash operations.
- Setup and Initial Success:
- Successfully read the product ID and the Serial Flash Discoverable Parameters (SFDP).
- Entered Quad Mode successfully.
- Performed Write Enable and Erase Operations without issues (verified via the flag status register and status register).
Problem Description:
When trying to program a page:
Programming Command Execution:
- After sending the Program Page command, I read the flag status register and find the error bit is set (Flag Status Register = 0x90).
- This indicates that the program operation has failed.
Memory Mapped Read:
- After switching to memory-mapped mode to read the NOR flash content, I find that all locations are filled with 0xCC.
Debugging Steps Taken:
Erase Operation:
- I ensured the sector was erased before programming, and this operation was successful.
Write Enable:
- Confirmed that the write enable command was successfully issued before programming.
Address Alignment:
- Verified that the write address is aligned to the page size (256 bytes).
Flag Status Register Inspection:
- Observed that after issuing the program page command, the error bit is set in the flag status register (Flag Status Register = 0x90).
Attachments:
I’m attaching:
- A screenshot showing the result in memory-mapped mode (all 0xCC values).
- My main.c file.
- The driver file (MT25QL512ABB.c) for the NOR flash.
- A screenshot showing the CubeMX configuration
Thank you in advance for your support and suggestions!
Hello Kaouthar and ST Community,
Thank you for your suggestions regarding the QSPI_MemoryMapped example and the configuration of the device size and dummy cycles. I truly appreciate the guidance.
I would like to provide some additional details and clarify the steps I have taken so far:
Steps Taken:
Device Size Configuration:
I have configured the device size in STM32CubeMX as 26 to match the 512Mbit size of the MT25QL512ABB flash memory.Dummy Cycles:
I have carefully set the dummy cycles to align with the specifications of the NOR flash, and I’ve verified that the configuration is correct.Driver Compatibility:
I am using the driver provided by ST on GitHub for the exact NOR flash model (stm32-mt25ql512abb), ensuring compatibility.QSPI_MemoryMapped Example:
I have already reviewed and tested the QSPI_MemoryMapped example. I also cross-checked its implementation with my code for both configuration and usage of the OCTOSPI interface.
Observed Behavior:
Programming Failure:
I cannot program the first section of the NOR flash (address 0x0). After multiple attempts, I noticed:- Erasing Issue: The erase operation on the first section consistently fails. I verify the operation by checking both the status register and the flag status register.
- Reading Issue in Memory-Mapped Mode: When I switch to memory-mapped mode and read the flash, I find that the entire first section is filled with 0x00.
Unexpected Behavior:
- Initially, the memory at 0x0 was not programmable but contained default values.
- After some operations, I observed that the first section has been entirely overwritten with 0x00, even though programming operations were unsuccessful.
- Further erase attempts on this section fail consistently.
Specific Questions:
- Why is the first section of the NOR flash (0x0) entirely filled with 0x00 after failed programming attempts?
- Why do erase operations on the first section fail after it has been filled with 0, even though they succeed on other sections?
- Could there be a hardware-related issue (e.g., write protection, alignment, or OCTOSPI-specific behavior)?
If anyone has encountered a similar issue or has further insights, I would be grateful for your support.
Thank you again for your assistance!
Best regards,
Feten Kortoba
