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!

[Pavel A.]

The IAR .mac files are scripts (macros) executed by debugger, in this case  to prepare for the loader. They must contain certain functions called by the debugger. Example attached.

[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]

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

By not being reliant on third-parties for deliver in my time lines..

Heck if we wait for Boeing to fix Starliner, NASA will have already contracted SpaceX to de-orbit the International Space Station, and SpaceX would have done so..

Probably going to need to fix/check the .MAC file and rebuild/fix the "Loader"

The .MAC describes the pin attribution, double check the OLD vs NEW pin assignments per the schematic and board revision you're working with.

#TeamKEIL

[Tesla DeLorean]

https://www.st.com/resource/en/schematic_pack/mb1191-f746ngh6-c01_schematic.pdf

CLK PB2:AF9

NCS PB6:AF10

D0 PD11:AF9

D1 PD12:AF9

D2 PE2:AF9

D3 PD13:AF9

I'd remove the "OLD ASSIGNMENT" section from the .MAC file, this connects up PF6,7,8,9

[Tesla DeLorean]

I can find the materials in basically a double packed ZIP archive

STM32Cube_FW_F7_V1.17.1\Utilities\PC_Software\patch\EWARM\EWARM_v7_ValueLine_STM32F7x0x8_Support.zip

Check

EWARM_v7_ValueLine_STM32F7x0x8_Supportv4.0\arm\config\flashloader\ST\FlashSTM32F7xx_QSPI_STM32F7508-DISCO.mac

EWARM_v7_ValueLine_STM32F7x0x8_Supportv4.0\arm\config\flashloader\ST\N25Q128A_STM32F7508-DISCO.out (.ELF file)

Example of IAR's loader model

https://github.com/gabrielleLQX/Downloads/blob/master/SAM3S%20Getting%20Started/src/flashloader/Atmel/at91sam3s-ek/framework2/flash_loader.c

https://updates.iar.com/FileStore/STANDARD/001/001/665/arm/doc/FlashLoaderGuide.ENU.pdf

Older

http://www.iarsys.co.jp/download/LMS2/arm/7502/ewarm7502doc/arm/doc/FlashLoaderGuide.ENU.pdf

https://community.nxp.com/pwmxy87654/attachments/pwmxy87654/kinetis/51087/1/FlashLoaderGuide.ENU.PDF

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