Code is working when it is in debug mode, but once disconnect the st-link nothing is working

[NAdim.1]

Hello All,

I am working on project using STM32Cube IDE

Recently I'm facing an issue like everything is working, when it is in debug mode.

But when I disconnect the st-link nothing is working.

And the project is in end stage and all of sudden I'm facing this issue.

Thanks in advance for comments and suggestions.

[Tesla DeLorean]

Very little detail to work from here..

Custom board? BOOT0 pulled low?

Diagnostic output via a serial port? Instrumented Hard Fault and Error Handler so you can see if it went there to die?

Use some GPIO or other signalling to establish how deep into your code it got before it dies?

[Bob S]

Which CPU?

Has your code EVER worked without the debugger?  Or is this a new thing?

Starting from the debugger is different than non-debugger power-on reset.  The debugger forces the PC to the starting address given in the ELF file.  When booting without the debugger the starting address (and starting stack pointer) comes from the vector table. 

Search your code for the USER_VECT_TAB_ADDRESS define.  For STM32F4 it is in system_stm32f4xx.c.  Make sure that is set to 1

[Tesla DeLorean]

stm32g070rbt6 I believe based on prior postings.

If BOOT0 floats or related optioning is wrong it might not start the primary firmware image at 0x08000000

Watch also for assumptions about hardware / clock initialization. The debugger might change a few things to suit it's needs, perhaps GPIOA, but other internal settings too.

Code early in the Reset_Handler can be used to initialize some clocks, and toggle GPIO, set LED, or output a character to a UART. This might to be done in assembler to quick establish life. In most cases the core will start, often crashing into a silent while(1) loop to be hard to track. Say the clock or PLLs fail to start promptly.

Use the Error_Handler(__FILE__, __LINE__); form to quickly establish where the error was thrown. Similarly with asserts()

I'd very strongly advise to get a serial port working to understand system behaviour absent a debug pod.