The behavior of the External Loader (H750B-DISCO) and the CubeProgrammer seems to be abnormal

[nonoriri]

Hello, I have a question regarding the subject.
Thank you always for your great answers. They have been very helpful :grinning_face:

[Reproduction Steps]

1. In CubeProgrammer, select the following External Loader:

MT25TL01G_STM32H750B-DISCO.stldr
> C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin\ExternalLoader

> The Page Size is 0x1000, but according to the Datasheet, I believe the correct value should be 0x100.

2. In the Erasing & Programming menu, select Full chip erase.

3. In the Erasing & Programming menu, select a 4-byte binary file and start programming.

Binary content: 0xA1B2C3D4
Start address: 0x98000000

> The STM32H750B has 1Gbit, so the range should be 0x90000000~0x97FFFFFF.

> Even if you write to 0x98000000, Download & Verify succeeds. (??? should not be accessible)

4. In the Memory & File editing menu, specify the address 0x97FFFFF0 and read.
> Data is written at the 0x98000000 location.

5. In the Erasing & Programming menu, select a 4-byte binary file and start programming.

Binary content: 0xF5E6D7C8
Start address: 0x98000000

> This time, "Error: Download verification failed" occurs.

6. In the Memory & File editing menu, specify the address 0x97FFFFF0 and read.
> The data at the 0x98000000 location is suspicious.

7. If you try to write a 4-byte binary to addresses like 0x98000004/0x98000008, it fails.
> This is the correct behavior.

[Questions]
These questions related to the `MT25TL01G_STM32H750B-DISCO.stldr`.

Q1. Is the Page Size of 0x1000 incorrectly specified?

Q2. Why is it possible to write data to 0x98000000?

Q3. Although there is no source code, if I check the assembly, `hqspi.Init.FlashSize` is set to 27.
Since 27 corresponds to 2Gbit Flash size, it should be 26 for the H750B.
Is there a reason for set 27?
By the way, when I create the External Loader from scratch and set FlashSize to 26,
there was a problem where the last 2 bytes of the 0x97FFFFFE~0x97FFFFFF range referenced incorrect values in CubeProgrammer and CubeIDE(debug) after entering Memory Mapped Mode.
So, was 27 set to avoid this issue for `MT25TL01G_STM32H750B-DISCO.stldr`?

[nonoriri · Accepted solution]

I think this is related to following thread.

https://community.st.com/t5/stm32-mcus-products/stm32h7-crashes-when-reading-the-last-bytes-from-a-memory-mapped/td-p/169513

https://community.st.com/t5/stm32-mcus-products/h7-quadspi-weirdness/m-p/258686

Also, the errata sheet ES0392 mentions the same problem.

Which is a better approach?

1. FSize + 1
   • Allow overflow access to the flash when using STM32CubeProgrammer
2. Do not change FSize
   • Do not write to the last 4 bytes