Release version of KEIL project much slower than debug version on STM32F413 MCU, why?

[mnoro.1]

I have developed firmware on STM32F413 with STM32CubeMX using FreeRTOS. I have several tasks and PPP connection over Serial (PPPoS). I am using KEIL IDE for debug and everything is OK in debug mode and after debug without resetting MCU. But when I powered off it and then power on again, operations were 8X slower (sending data over UDP on PPPoS can be slow!). There is no error in data transferring, only the unexpected slowdown.

I have tested it with STM32CubeProgrammer too by flashing 

.hex

 file and running it with STM32CubeProgrammer, and everything is OK! After I power down and on again, the problem recurs.

I notice that in debug, KEIL uses object files. But I cannot understand what is different between the power-on MCU situation (booting time) vs. debug time.

How I can fix this problem?

Can anyone help?

[waclawek.jan]

Do you use some of the low-power modes (sleep etc.), directly or indirectly (i.e. FreeRTOS uses it)?

JW

[mnoro.1]

I'm using FreeRTOS and have a IdleTask but I am not using low-power modes. (USE_TICKLESS_IDLE = Disabled)

[Tesla DeLorean]

Print out the SystemCoreClock value. Make sure it's clocking at expected speeds. If not look at how the clocks and PLL are configured.

[mnoro.1]

I checked the SystemCoreClock with RCC_MCO. It is OK!

[waclawek.jan]

Instrument key portions of your code by toggling pins around them,and observe using oscilloscope/LA; comparing the "good" and "bad" cases.

JW

[Pavel A.]

@mnoro.1​ Is your subject line misleading? It looks like there are not two binaries (debug vs release) but different behaviors of the same binary with debugger attached vs not attached?

[mnoro.1]

Thanks, I will check it.

[mnoro.1]

Yes, a binary seems to behave well when it is programmed for a first time and debugger is connected yet, but it behaves differently at other times. I do not know what the reason is and where it comes from.

Can you guide me? @Pavel A.

[mnoro.1]

I rechecked reset scenario and find that with longer reset signal everything be OK!

I increased nRST pin capacitor value and problem have been resolved.

STM32F413 datasheet recommends 100nF value for capacitor but it is not good in my case.

The only thing that I don't understand yet is that why with other codes I haven't this problem? and why in this case it works slowly (instead not completely wrong)?