STM32h755ZI-Q Crashes on a particular code only

[Obaid_tanveer]

Hi Guys,
I am recently facing a very rare problem on stm32 nucleo h755zi- q 

i am working with ltc6804ic for a BMS and am facing the following issue:
Whenever i upload the code on the stm32 it crashes, and says no debung info available etc, 
after this i can not upload any code to the board unless i pull the boot0 pin to 3.3 (CubeIde says no stlink connected).
Each time this happens i have to put the MCU to boot mode and then connect to it via the cube programmer and then i have to mass erase the chip , after this the board works fine with every other code, except my main code, 
on top of that , the same was working fine on the same board and randomly works fine like lets say 1 out of 10 times, (same code , no changes made, works sometime , some time it doesn't )
This is not a STLINk problem for sure (looks like one when the cube ide says no stlink detected or cant enter debug mode etc etc , i have attached some screenshots to explain what happens after the code crashes). i am using SPI,CAN,UART,Ethernet on the MCU , now there night be something wrong with the code , i have developed this code on the nucleo h743 board and the whole thing works fine , and it never crashed , i had to move to the h755 zi-q board as the 743 has gone obsolete,
If we consider that  something is wrong with the code, or some memory leak then why this never happened on the other board. this is an extremely confusing thing. if someone could have answers,
can it be something with the code size ? it is 168kb's and each bank in this board is 128kb , but then again , it worked fine on the 743 board which has the same memory sectors and banks

even if i to try to find out that if there is something wrong in the code , i tried porting the code from the h743 board one by one (from led blink to enabling and using the spi , then fdcan then uart, ethernet and the save to memory thing), the code starting working , everything was fine until i tried to put it in the debug mode , everything got messed up, i am unable to burn the same code since then , if i mass erase the chip and then burn any other code like i have lots of firmwares, they work fine . idk what to do , if anyone has  ever faced anything like this please let me know of anything i could try..

Looking forward for any suggestions, solutions or anything i might be missing.

[TDK]

Ensure the power configuration and clock settings are valid, and that the chip doesn't erase/write flash during the first 1s of operation.

If you think it's a code bug, perhaps show the code.

[Obaid_tanveer]

i have rechecked these, none of these seems to be the issue, also with the same clock and power config it worked on the h743 board and it also worked on this h755 board a couple of times, is there something else i could look into?
can it be something with some configurations made when we enter debug mode, (i also tried deleting the debug folders from the project directory and building the project again , i tried writing the individual hex files to the MCU and powering it from the external supply. it didn't help either)

[Obaid_tanveer · Accepted solution]

Thanks for the suggestions regarding the power configuration or clock issue preventing me from entering debug mode or causing the system to crash on my STM32H755ZI Q. I was initially unable to debug the M4 core, and system crashed if i tried to.

I found that commenting out the following lines in my code allowed me to enter debug mode successfully:

// HAL_PWREx_ClearPendingEvent();

// HAL_PWREx_EnterSTOPMode(PWR_MAINREGULATOR_ON, PWR_STOPENTRY_WFE, PWR_D2_DOMAIN);

// /* Clear HSEM flag */

// __HAL_HSEM_CLEAR_FLAG(__HAL_HSEM_SEMID_TO_MASK(HSEM_ID_0));

Without these lines commented, the system would hang, likely because the M4 core was entering STOP mode or expecting the M7 core to handle a hardware semaphore (HSEM) event, which didn’t occur due to the M7 being halted or not synchronized during debug. Since I was debugging only the M4 core, this mismatch caused

conflicts, possibly a deadlock or resource contention, which lead to the crash.

[TDK]

Entering low power mode during the first 1s of operation will also kill the debugger connection.