STM32CubeIDE v1.8.0 flashing error: Data mismatch found at address

[Watchdog28]

Hi,

Since I updated the STM32CubeIDE to v1.8.0 each second flash process fails with Error: Data mismatch found at address. With the STM32CubeIDE v1.6.0 everything works fine.

In the project the start address of the flash area is set to 0x08010000 because on 0x08000000 the bootloader is located.

STMicroelectronics ST-LINK GDB server. Version 6.0.0
Copyright (c) 2021, STMicroelectronics. All rights reserved.
 
Starting server with the following options:
        Persistent Mode            : Disabled
        Logging Level              : 1
        Listen Port Number         : 61234
        Status Refresh Delay       : 15s
        Verbose Mode               : Disabled
        SWD Debug                  : Enabled
        InitWhile                  : Enabled
 
Waiting for debugger connection...
Debugger connected
Waiting for debugger connection...
Debugger connected
Waiting for debugger connection...
      -------------------------------------------------------------------
                       STM32CubeProgrammer v2.9.0-RC01                  
      -------------------------------------------------------------------
ST-LINK SN  : 49FF67066584525744110987
ST-LINK FW  : V2J39S7
Board       : --
Voltage     : 3.24V
SWD freq    : 4000 KHz
Connect mode: Under Reset
Reset mode  : Hardware reset
Device ID   : 0x469
Revision ID : Rev X
Device name : STM32G47x/G48x
Flash size  : 512 KBytes
Device type : MCU
Device CPU  : Cortex-M4
BL Version  : --
 
Memory Programming ...
Opening and parsing file: ST-LINK_GDB_server_a12924.srec
  File          : ST-LINK_GDB_server_a12924.srec
  Size          : 131168 Bytes
  Address       : 0x08010000 
 
Erasing memory corresponding to segment 0:
Erasing internal memory sectors [32 96]
Download in Progress:
File download complete
Time elapsed during download operation: 00:00:03.485
Verifying ...
 
Error: Data mismatch found at address  0x08010000 (byte = 0xFF instead of 0x00)
Error: Download verification failed
Shutting down...
Exit.

The first 8 bytes were not programmed.

MCU: STM32G474

Programmer: ST-Link/V2

On an erased flash the flash process (triggered via STM32CubeIDE Run/Debug) is working. Afterwards each second flash process fails. Maybe the problem is located in the updated STM32CubeProgrammer. I have tried different debugger settings without success.

Thanks for any help.

[Markus GIRDLAND]

Hello there!

First a question to pinpoint where the problem lies. Could you try to use CubeProgrammer stand alone application and see if it's still the same issue where it only flashes ever second time?

Secondly, if you go to the Startup tab of your Debug Configuration and add this following command to the Initialization Commands does the behavior change?

monitor flash mass_erase

[Watchdog28]

Hi Markus,

With the mass erase initialization command the flash process works every time but the bootloader will be cleared.

I have installed the latest STM32CubeProgrammer (v2.9.0). With the GUI tool and with the STM32CubeProgrammer_CLI.exe it works fine. I also tried the STM32CubeProgrammer_CLI.exe delivered with the STM32CubeIDE plugin (com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_2.0.100.202110141430) flashing an ELF file without success. Data mismatch on every second execution. The version of the STM32CubeProgrammer_CLI.exe from the plugin is v2.9.0-RC1. It seems the problem only occurs in the -RC1 version.

Is there a way to downgrade the external tools?

[Markus GIRDLAND]

Hello again,

A new version of STM32CubeIDE will probably go live later today (if not today then in the coming days for sure) which includes a new version of CubeProgrammer.

Hopefully this problem will no longer be present with the new version and if it's still there we can look into the possibility of downgrading external tools. It's not something I have done myself so I would probably need to experiment a bit with it first.

[Watchdog28]

Hi,

I have updated to STM32CubeIDE v1.9.0 and STM32CubeProgrammer v2.10.0 is used. Unfortunately this did not solve the problem.

[LBend.1]

Hi,

I too have the similar issue: When I flash a brand new processor solely via STM32CubeProgrammer v2.10.0 I get data mismatches, but not always in the same location. In STM32CubeIDE when run/debug my device programs fine. But, after I program via STM32CubeIDE once successfully and then with STM32CubeProgrammer to flash again, my program seems to work, but the second mismatch occurred.

First Attempt:

  09:47:42:749 : r ap 0 @0x905EC000 0x00000400 bytes Data 0xFFE8E8E8
  09:47:42:749 : Error: Data mismatch found at address  0x905EC200 (byte = 0xFF instead of 0xE8)
  09:47:42:750 : Error: Download verification failed

Second Attempt:

  10:00:37:043 : r ap 0 @0x90000000 0x00000400 bytes Data 0x00000000
  10:00:37:044 : Error: Data mismatch found at address  0x90000014 (byte = 0x00 instead of 0xD8)
  10:00:37:044 : Error: Download verification failed

[LaurentL]

Hello,

The addresses you are showing are not in Flash of the STM32 device but on external memory.

Did you select the ext memory in the debug configuration ?

You should select the same external flash memory as in STM32CubeProgrammer.

Rgds,

Laurent

[Tesla DeLorean]

This is the address range of the external QSPI NOR Flash, you need an external loader (.STLDR) capable of supporting your flash part, in your board design.

A lot of factors can effect your ability to program the memory, not least the electrical integrity of your design.

As part of your own design validation processes you should have the QSPI BSP package for your board test and stress the memory interface, so all the clocking and timing matches the design, then port those settings into your external loader. At that point it should be significantly more robust.

[LBend.1]

Hi Laurent,

Thanks for the insight! For more clarity this project is on an STM32F746-DISCO board, with a TouchGFX GUI interface. I don't think I specifically setup anything for ext memory, but maybe the ToughGFX integration sets some of that up?

The only memory definition changes I made were in the FLASH.ld file. I used sector 8 in flash for some long term non-volatile initialization storage.

/* Memories definition */
MEMORY
{
  RAM     (xrw)  : ORIGIN = 0x20000000,  LENGTH = 320K
  FLASH   (rx)   : ORIGIN = 0x8000000,   LENGTH = 768K  /*Original Size was 1024K, subtracted 256K*/
  QUADSPI (r)    : ORIGIN = 0x90000000,  LENGTH = 16M
  DATA 	  (rwx)  : ORIGIN = 0x080C0000,  LENGTH = 256K
}

I am using an external loader in the Run and Debug configurations (i.e. N25Q128A_STM32F746G-DISCO, 0x90000000, NOR_FLASH, N25Q128A_STM32F746G-DISCO.stldr) configuration defined for the STM32F746G-DISCO. Is that the right external loader configuration to use for the STM32F746G-DISCO?

Thanks!

Logan

[LBend.1]

Hi Tesla,

I appreciate the response! These programming errors are occurring on an STM32F746G-DISCO board from STM32. I am using an external loader in the Run and Debug configurations (i.e. N25Q128A_STM32F746G-DISCO, 0x90000000, NOR_FLASH, N25Q128A_STM32F746G-DISCO.stldr) configuration defined for the STM32F746G-DISCO. This was the only configuration I could find and didn't attempt to build any.

I just tried to look up the BOM for the QSPI in the STM32F746-DISCO and it looks like maybe it is a MT25QL128ABA1EW9-0SIT, but I'm unsure of that? Which doesn't match the .stldr configuration currently used. However the confusing part to me is that when I program in STM32CubeIDE I get no apparent issues, but in STM32CubeProgrammer the errors exist with the built .hex file.