STM32F746 IAR QSPI Verification error

[Alex_777]

Hello.

I am using mb1191-F746NGH6-C01, IAR Embedded Workbench for ARM 9.50.1.69506, CubeMX V6.12.1 and

TouchGFX V6.22.0. I generated the project in TouchGFX for IAR. TouchGFX locate the backgrounds and widgets in external flash memory. The Discovery STM32F746 board has MT25QL128ABA1EW9 memory.

In IAR I select "Use Flash Bootloader"

Select STM32F746G-DISCO_QSPI.flash

When I press the button "Download and Debug"

I have the next information in the log:

Wed Oct 16, 2024 21:00:42: Hardware reset with strategy 0 was performed

Wed Oct 16, 2024 21:00:42: Verification error at 0x9000'0000: mem = 0x00, file = 0x0B

Wed Oct 16, 2024 21:00:42: Download completed but verification failed.

Wed Oct 16, 2024 21:00:42: Hardware reset with strategy 0 was performed

Wed Oct 16, 2024 21:00:42: Target reset

Wed Oct 16, 2024 21:00:42: There were 1 error and 1 warning during the initialization of the debugging session.

Memory window in the IAR

Part of the array where it is stored backgrounds image

LOCATION_PRAGMA("ExtFlashSection")

KEEP extern const unsigned char image_alternate_theme_images_backgrounds_480x272_gradient_dark[] LOCATION_ATTRIBUTE("ExtFlashSection") = { // 480x272 RGB565 pixels.

    0x0b, 0x2a, 0x0b, 0x2a, 0x0b, 0x22, 0x2c, 0x2a, 0x2b, 0x2a, 0x2c, 0x2a, 0x0b, 0x2a, 0x2b, 0x2a,

    0x2c, 0x2a, 0x0b, 0x22, 0x2c, 0x2a, 0x2c, 0x2a, 0x2b, 0x2a, 0x0b, 0x2a, 0x2c, 0x2a, 0x2c, 0x2a,

    0x2c, 0x2a, 0x2b, 0x22, 0x2c, 0x2a, 0x2c, 0x2a, 0x2c, 0x2a, 0x2c, 0x2a, 0x4c, 0x2a, 0x4c, 0x2a,

    0x2c, 0x2a, 0x2c, 0x2a, 0x2c, 0x2a, 0x2c, 0x2a, 0x4c, 0x2a, 0x2c, 0x2a, 0x4c, 0x2a, 0x4c, 0x2a,

    0x4c, 0x2a, 0x4c, 0x2a, 0x4c, 0x2a, 0x4c, 0x2a, 0x4c, 0x2a, 0x4c, 0x2a, 0x4c, 0x2a, 0x4c, 0x2a,

    0x4c, 0x2a, 0x4c, 0x2a, 0x4c, 0x2a, 0x4c, 0x2a, 0x4c, 0x2a, 0x6d, 0x32, 0x4c, 0x2a, 0x4c, 0x2a,

    0x4c, 0x2a, 0x4c, 0x2a, 0x4d, 0x2a, 0x6d, 0x32, 0x6c, 0x32, 0x6d, 0x2a, 0x6d, 0x32, 0x6d, 0x32,

 

1) I can't understand what the file = 0x0B means in the following error?

Wed Oct 16, 2024 21:00:42: Verification error at 0x9000'0000: mem = 0x00, file = 0x0B

2) Where can I find this file?

3) I don't understand why there is a verification error? Where did I make a mistake?  Perhaps additional settings need to be made? I would be very grateful for any help and ideas.

The project is attached to this post.

Thanks!

 

 

 

 

 

 

 

 

 

 

[Tesla DeLorean]

File would be the .ELF and the section within the object file describing the 0x90000000 address space.

The memory dump from the debugger, via memory mapping looks ok.

The external loader from IAR seems to be having less success reading the content it just wrote.

[Alex_777]

Great thanks for answer.

I did't find the .elf file in the iar directory with my project.

Do I understand correctly that the equivalent of an .elf file is a file with the .out extension ?

I looked at the contents of the .out file and didn't find the section within the object file describing the 0x90000000 address space.

Do I understand correctly that the verification error is only related to the IAR, and everything is fine on my side?

What development environment would you recommend instead IAR Embedded Workbench?

Thanks.

[Mohammad MORADI ESFAHANIASL]

Hello @Alex_777,

TouchGFX supports IAR Embedded Workbench, and if you use the provided TouchGFX Board Setup (TBS) for the STM32F746G Discovery Kit, then you can open the STM32CubeMX project (.ioc file), and change the Toolchain/IDE from the "Project Manager" tab to EWARM, and press generate code. Then, from your TouchGFX project, you have generate code as well. By navigating to the EWRAM folder in your project's directory, you can access the IAR project. The required settings are already provided; therefore, you don't need to change anything. 

TBS for STM32F746G Discovery Kit

EWARM directory

If you still have trouble downloading the program to your board, you can compile the program by IAR, and use the outputted .hex file to download on your board with STM32CubeProgrammer. You can read more about this process here.

I hope this helps you! 

[Alex_777]

Hello, Mohammad MORADI ESFAHANIASL

Thanks for reply.

You wrote the next:

TouchGFX supports IAR Embedded Workbench, and if you use the provided TouchGFX Board Setup (TBS) for the STM32F746G Discovery Kit, then you can open the STM32CubeMX project (.ioc file), and change the Toolchain/IDE from the "Project Manager" tab to EWARM, and press generate code. Then, from your TouchGFX project, you have generate code as well. By navigating to the EWRAM folder in your project's directory, you can access the IAR project. The required settings are already provided; therefore, you don't need to change anything. 

I know about it and it was my first actions yesterday. If I do as you write, I get the following error:

Flash download warning: 358130 out of 358130 bytes from data record CODE:[0x9000'0000,0x9005'76f1] will not be flashed. 

If I enter the settings that I wrote above, I get an error only with verification.

What could be the problem?

Thanks.

[Pavel A.]

>  mb1191-F746NGH6-C01

Is this board the STM32F746G_DISCO? External flash loaders should match the board (actually, pinout of QSPI controller and the flash chip).

The .board files of IAR EWARM are text files that list the used "external loaders" and their parameters. A board can have several external memories and several loaders.

> I did't find the .elf file in the iar directory with my project.

IAR creates tweaked .elf files with extensions "out" and "sim" (simplified?). 

 

[Alex_777]

Yes, I have STM32F746G DISCO. I understand that the external flash loaders should match the board.

In the IAR I use the file FlashSTM32F746G-DISCO_QSPI.flash

Below is the content of this file:

<?xml version="1.0" encoding="iso-8859-1"?>
<flash_device>
<exe>$TOOLKIT_DIR$/config/flashloader/ST/FlashSTM32F7xx_QSPI_MICRON.out</exe>
<page>256</page>
<block>256 0x10000</block>
<flash_base>0x00000000</flash_base>
<macro>$TOOLKIT_DIR$/config/flashloader/ST/FlashSTM32F746G-DISCO_QSPI.mac</macro>
<aggregate>1</aggregate>
</flash_device>

Do I understand correctly that QSPI_MICRON is the MT25QL128?

How can one be sure of this?

[Alex_777]

As for the program STM32CubeProgrammer, it does not support the memory MT25QL128, you need to create the .stldr file manually.

Memory chips N25Q128A and W25Q128J has the same page size - 256 bytes.

Why do we see different page sizes in STM32CubeProgrammer?

 

 

[Tesla DeLorean]

The N25Q128 is just a much earlier variant of the Micron part, perhaps with an older die, when ST/Micron were fab partners. I'd imagine the newer parts have shrunk die to increase wafer yield as part of Micron's longevity model, which is form-fit-function not making the same die for decades, allowing them to pivot into new tighter geometries as fab tech advances. 

Similarly the page size of both the Micron and Winbond are 256 bytes. The loader does the deblocking internal when given a large buffer. Cube Programmer uses this value as a guide to how to align Write() requests on a address and size basis.

The Winbond and Micron have slightly different architecture, and management of status registers and mode.

Old and new Micron parts are subtly different but shouldn't cause failure. Some issue with IAR's script here

[Alex_777]

Today I did the following experiment. Using IAR Embedded Workbench, I loaded firmware into the STM32F746 Discovery board.
Then I read the contents of the external flash memory using the SMT32CubeProgrammer and compared the read values ​​with the hex file generated by IAR. These values ​​completely matched. From this I conclude that the verification error is related to a flaw on the IAR side.
So far I have not found a way to fix this error and simply disabled the verification option as shown below.

I really hope that the company ST Microelectronics, in cooperation with IAR, will correct this error soon.

If anyone has encountered a similar problem, please write. I wonder how you solved this problem.

Thanks!

 

[Pavel A.]

>  I conclude that the verification error is related to a flaw on the IAR side.

As IAR customer (paying for support) you can approach IAR right now, not waiting for ST.

 

[Tesla DeLorean]

The .OUT file for the STM32F7508-DK looks to enable clocks and set up pins

https://www.st.com/en/evaluation-tools/stm32f7508-dk.html

I could probably rebuild, or patch, these if necessary, but can't say I've had much demand

[Alex_777]

 

I am using the FlashSTM32F746G-DISCO_QSPI.mac file.

I checked the pin assignments on the debug board against the .mac file. Everything is correct there.

Then I compared the files: EWARM_v7_ValueLine_STM32F7x0x8_Supportv4.0\arm\config\flashloader\ST\FlashSTM32F7xx_QSPI_STM32F7508-DISCO.mac and FlashSTM32F746G-DISCO_QSPI.mac

The only difference is that in the FlashSTM32F746G-DISCO_QSPI.mac file the /* Enable and Reset QSPI */ section is at the end of the file, while in the FlashSTM32F7xx_QSPI_STM32F7508-DISCO.mac file it is at the beginning.

I put the /* Enable and Reset QSPI */ section at the beginning of the FlashSTM32F746G-DISCO_QSPI.mac file, but it did not affect the operation.

I also have a STM32F7508-DK debug board.

I patched the IAR files in the directories:

debuger

devices

flashloader

linker

from the zip archive: STM32Cube_FW_F7_V1.17.1\Utilities\PC_Software\patch\EWARM\EWARM_v7_ValueLine_STM32F7x0x8_Support.zip

When loading the project in the STM32F7508-DK, the same verification error occurs as for the STM32F746-DK.

Then I tried to work with stm32CubeIDE.
There were no verification errors. But after loading data into flash memory (stm32f7508-dk board) the following error occurred

No source code for "_binary_______ExtMem_Boot_Binary_Bootloader_bin_start() at 0x8001ece"
A similar problem was discussed here:

https://community.st.com/t5/stm32-mcus-touchgfx-and-gui/can-not-run-debug-touchgfx-on-stm32f750n8h6-stm32f7508-dk/td-p/166373

But as far as I understand, no solution has been found.

There is no such error when using the stm32f746-dk board. I think it has to do with the fact that the stm32f746 chip has more RAM than the stm32f7508.
I also see the fact that ST has not found a solution to this problem, although a lot of time has passed. The solution that I found empirically is resetting the controller with the reset button. But this is not quite what I would like to see.

Let's summarize:
1) There are problems with the interaction of ST debug boards with the IAR and STM32CubeIDE debugging environments
2) Many thanks to Tesla DeLorean and everyone else for their help. I think there is no point in wasting effort and resources in this direction. There is still a lot of work to focus on.