STM32H7A3ZI: Flash verification fails if UART/USART interface is enabled

Programmer/board type: [STLINK V3]
Operating system an version: [Linux]
stlink tools version and/or git commit hash: [v1.7.0-195-g951859c]
stlink commandline tool name: [st-flash]
Target chip (and board, if applicable): [STM32H7A3ZI (Nucleo-H7A3ZI-Q)]

Further we kindly ask you to describe the detected problem as detailed as possible and to add debug output if available, by using the following template:

Commandline output:

$st-flash --reset write build/h7a3zi_test.bin 0x08000000

st-flash 1.7.0-195-g951859c
Failed to parse flash type or unrecognized flash type
2022-05-18T11:23:19 INFO common.c: STM32H7Ax_H7Bx: 128 KiB SRAM, 2048 KiB flash in at least 8 KiB pages.
file build/h7a3zi_test.bin md5 checksum: f56fd507ca1329599bac3afb7c645, stlink checksum: 0x00152999
2022-05-18T11:23:19 INFO common_flash.c: Attempting to write 13832 (0x3608) bytes to stm32 address: 134217728 (0x8000000)
-> Flash page at 0x8000000 erased (size: 0x2000)
-> Flash page at 0x8002000 erased (size: 0x2000)

2022-05-18T11:23:19 INFO flashloader.c: Starting Flash write for H7
13832/13832 bytes written
2022-05-18T11:23:19 INFO common_flash.c: Starting verification of write complete
2022-05-18T11:23:19 ERROR common_flash.c: Verification of flash failed at offset: 6144
stlink_fwrite_flash() == -1

Expected/description:
While testing the board, we noticed that st-flash fails during the verification phase if a UART/USART interface is enabled through STM32CubeMX.
By flashing the same build with STM32CubeProgrammer, no issues appears during the write and the verification phases.

The code is fully generated by STM32CubeMX with a small addition by ours to transmit a sample text on USART3 every 100 ms

We replicated this behavior on two different machines (Pop!_OS 20.04 on Intel i7-9850H and Ubuntu 20.04.4 on Intel i7-7700HQ)

@EmanueleGiacomini Can you try use connect under reset?
st-flash --connect-under-reset --reset write build/h7a3zi_test.bin 0x08000000

@EmanueleGiacomini Can you try use connect under reset? st-flash --connect-under-reset --reset write build/h7a3zi_test.bin 0x08000000

We've just tested but the output seems unchanged

$st-flash --connect-under-reset --reset write build/h7a3zi_test.bin 0x08000000
st-flash 1.7.0-195-g951859c
Failed to parse flash type or unrecognized flash type
2022-05-18T12:30:40 INFO common.c: STM32H7Ax_H7Bx: 128 KiB SRAM, 2048 KiB flash in at least 8 KiB pages.
file build/h7a3zi_test.bin md5 checksum: f56fd507ca1329599bac3afb7c645, stlink checksum: 0x00152999
2022-05-18T12:30:40 INFO common_flash.c: Attempting to write 13832 (0x3608) bytes to stm32 address: 134217728 (0x8000000)
-> Flash page at 0x8000000 erased (size: 0x2000)
-> Flash page at 0x8002000 erased (size: 0x2000)

2022-05-18T12:30:40 INFO flashloader.c: Starting Flash write for H7
13832/13832 bytes written
2022-05-18T12:30:40 INFO common_flash.c: Starting verification of write complete
2022-05-18T12:30:40 ERROR common_flash.c: Verification of flash failed at offset: 6144
stlink_fwrite_flash() == -1

Edit: If it can be of help, we have the same issue on another project which wrote and verified on STM32H723ZG (Nucleo-H723ZG). After a porting on the current board, we started facing this issue.

@defyingphysics Please also take a look at #1184. Thanks.
It is yet unclear if there is a connection between current H7-related issues.
We need to investigate.

@Nightwalker-87 Used correct value of cmp_size. There not is a significant difference between comparing by a page or a part of page.

It's strange that UART affects. Perhaps UART used together with DMA. DMA clocking must be disabled in RCC (perhaps something is not working correctly...):

stlink/src/stlink-lib/flashloader.c

Lines 145 to 148 in d053470

    
           case STM32_FLASH_TYPE_H7: 
        
             rcc = STM32H7_RCC_AHB1ENR; 
        
             rcc_dma_mask = STM32H7_RCC_DMAEN; 
        
             break;

@Ant-ON I see. Can you check with applicable (maybe not the same) hardware?
What do you have available BTW? I do have a STM32VL Discovery Board, a self equipped STM32F103 Bluepill (so no-fake chip!) and a Blackpill-Board, but they do not appear to be helpful here due to their device families.

@defyingphysics Please also take a look at #1184. Thanks. It is yet unclear if there is a connection between current H7-related issues. We need to investigate.

Left a message on the thread, hope it is what you are after. As mentioned, I have a H7A3ZI-Q that I can help run other tests on.
An update to this is I noticed it was not just the UART that was causing the issue, Enabling SPI seems to have a similar effect. These tests are all done with default projects, simply disabling and enabling functionality and trying to flash.

Following recent refactoring work, the code snippet in #1249 (comment) is now located in flash_loader.c:563.

I found these threads, which provide additional information and likely resolve this issue:

The provided references indicate that this topic is a more general issue and not (specifically) related to the stlink toolset.
As additional information has been given to address this issue, I am closing this issue now as it appears to be resolved.

Closes #1294.

	case STM32_FLASH_TYPE_H7:
	rcc = STM32H7_RCC_AHB1ENR;
	rcc_dma_mask = STM32H7_RCC_DMAEN;
	break;