Strange Boot Sequance on STM32H7

[HAlzo]

I am using STM32H7 for about 2 years with stable HW an SW .

after some SW change I found strange behavior .

If the debugger is connected and I flash the application using ICD "ST-Link Ver3" the micro-controller boot normally.

but the micro-controller hangs at start up after connecting power through USB, and starts normally if I press reset.

I understand that this problem may be reset or clock problem, but I did double check on clock configuration and reset circuit and they are according recommendations by ST.

In order to find where the application hangs, I connected the USB to power the board while ST-Link is not connected to the board, and after that I connected ST link and run ST-link utility to find the location of Program counter.

Then I loaded the application one more time using ST-Link and check the location of program counter,

I found that Program counter was stopping at Reset_Handler

and this is a snapshot from the linker file and map file

I restored previous version of SW in order to find the source of the Problem,

I found this code is the source of the problem

do
	{
		status = HAL_SPI_TransmitReceive_DMA(&hspi4,(uint8_t*)readRAMCommand,(uint8_t*)data,word_count);
		//while((HAL_SPI_GetState(&hspi4)==HAL_SPI_STATE_BUSY)||(HAL_SPI_GetState(&hspi4)==HAL_SPI_STATE_BUSY_TX_RX))
			;
	}while((status==HAL_ERROR)||(status==HAL_TIMEOUT));

and the source of the problem was the do while on SPI error

after removing this do while on SPI error, the application runs normally .

the next code run without any problem

status = HAL_SPI_TransmitReceive_DMA(&hspi4,(uint8_t*)readRAMCommand,(uint8_t*)data,word_count);

My questions are

1. what is the explanation of this error?
2. What is the right way to handle SPI errors, specially in case of using DMA?

[TDK]

Pretty sure connecting with ST-Link is going to change the state of the CPU.

You can attach a debugger in STM32CubeIDE without resetting the chip. Uncheck the "download program" and "reset" option in your debugging configuration.

You'll need to figure out why it's failing. Figure out the error code and go from there. Calling it again and again when it's failing is not a good approach.

> after some SW change I found strange behavior .

This is where I'd start looking.