Issue with Programming NOR Flash MT25QL512ABB1EW9 Using STM32H735IGT6

[feten_kortoba]

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:

1. 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.

2. 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:

1. A screenshot showing the result in memory-mapped mode (all 0xCC values).
2. My main.c file.
3. The driver file (MT25QL512ABB.c) for the NOR flash.
4. A screenshot showing the CubeMX configuration

Thank you in advance for your support and suggestions!

 

[KDJEM.1]

Hello @feten_kortoba,

 

Could you check the device size and the dummy cycle? The size of MT25QL512ABB memory is 512Mbits=64MBytes. So, in STM32CubeMX you need to configure Devise Size = 26.

May be this example can help you QSPI_MemoryMapped. This example has been tested with STM32G474E-EVAL

with MT25QL512ABB memory connected to QUADSPI interface. You can get inspired from this example to communicate the MT25QL512ABB with STM32H735 MCU using the OCTOSPI interface.

Thank you.

Kaouthar

 

 

[feten_kortoba]

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:

1. Device Size Configuration:
   I have configured the device size in STM32CubeMX as 26 to match the 512Mbit size of the MT25QL512ABB flash memory.

2. 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.

3. Driver Compatibility:
   I am using the driver provided by ST on GitHub for the exact NOR flash model (stm32-mt25ql512abb), ensuring compatibility.

4. 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:

1. 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.

2. 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:

1. Why is the first section of the NOR flash (0x0) entirely filled with 0x00 after failed programming attempts?
2. Why do erase operations on the first section fail after it has been filled with 0, even though they succeed on other sections?
3. 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

[Jacob WOODRUFF]

Hi All,

 

This post has been escalated to the ST Online Support Team for additional assistance. We'll contact you directly.

 

Regards,
Jake

ST Support