Is power cycle reset different as compared to reset pin reset?
Yes. There are some semiconductor behaviours where only loss of power will allow previous behaviour to resume. An SCR is a type of component where this behaviour (i.e. only loss of power allows previous state to resume) is normal, and SCR-like structures exist within most ICs.
Is this an expected behavior?
Depends what you mean by "this". Is it expected behaviour that you can provoke an extreme situation using unknown voltage ESD discharges on a live circuit, where only a power-cycle will recover? Yes
Can I do something to ensure my reset pin always works in such conditions?
Always, for the conditions of that test? Realistically, no - without extreme measures.
Based on your description, I suspect your ESD injection is triggering latch-up, sometimes called SCR latch-up (or a latch-up like behaviour) inside the MCU. Texas Instruments have a nice app note called Latch-Up, ESD, and Other Phenomena which contains information very relevant to your questions.
I was going to reply to your earlier question which you linked, but too many details were unclear to me, some decisions were based on assumptions that I disagreed with, and experience tells me it's unlikely I can add much in that situation. I also don't believe that your current test is realistic, in the context of your problems described in the previous question.
After all this, I was able to make my microcontroller hang up after torturing it for few minutes and I could repeat the hang up process. Success till this part.
I respectfully disagree that this is "success". What you have done is to provoke a similar symptom to your earlier question (i.e. MCU locks-up). But there are several possible root causes for that symptom - how do you know that you are triggering the same cause with the ESD gun, as with your device installed in its planned location? There was no evidence in your earlier question of direct ESD sparks onto the live PCB (which is an extreme test) - yet that is what you are now testing.
Therefore I see your current ESD test results as a bit like an XY-problem. You have the original problem with MCU lock-up. You weren't yet able to diagnose that. Now you have now found another way to trigger MCU lock-up (using direct ESD sparks). But that does not mean that direct ESD sparks are the cause of your original problem (therefore I wouldn't call ESD triggering an MCU lock-up a "success") - nor does it mean that any fixes designed to help with ESD protection would help with your original problem either.
I realise this sounds negative, sorry about that. I'm just suggesting that, based on many years experience of troubleshooting complex systems, you are quite likely to be "going down a rat hole" by following your current testing, as it may not help with your original problem.
Personally, if I was in your situation, I would be focussing on better diagnosing the original problem, rather than introducing a new (and, I believe unrealistic) test case. Best of luck!
My bet is on boot0; Check that you've got it pulled low.
The boot0 pin selects where the MCU will start executing code from when it boots up, ie. comes out of reset. If boot0 is low, it'll execute your code from flash, but if it's high, it'll execute the internal bootloader from the system memory.
My guess is that you have left boot0 floating, and when you're doing a cold boot (ie. disconnecting and reconnecting power), it'll be close to zero, so the MCU will boot your code from flash, but when you do a warm boot with the reset signal, the pin will have floated to a higher value, is read as high, and the MCU will boot to the internal bootloader from system memory instead of your code.
This explanation assumes you haven't touched the boot-related option bytes, which would change the behaviour. Also, in case you'll be working with different STM32 MCUs at some point, please note that they can have slightly different behaviour. Some have different boot-related option bytes. All I've seen so far have had a boot0 pin which behaves identically, but some also have a boot1 pin (which might be shared with a gpio pin) that you might also have to set correctly. In the MCUs I remember seeing, though, boot1 is only relevant if you want to be able to boot from system memory or SRAM.
Best Answer
The 4017 is clocked on the rising edge, and you have the clock line high when it comes out of reset.
Try connecting clock in to Vdd and the 555 output to inhibit in. Inhibit is just an inverted clock input (sans Schmitt trigger). Or add an inverter between 555 and clock in.
In general this is a really crummy reset circuit - criminally bad for anything important. Use a reset (supervisor) chip that provides a sharp fixed-length reset pulse out (eg. 200ms) and also detects slow brownouts and slow Vdd rise. They are plentiful and cheap, and designing one that is bulletproof is non-trivial.
If you insist on using this circuit, at least add a few K resistor in series with the reset input. Otherwise shorting or putting a heavy load turning Vdd off could damage the chip by discharging the 4.7uF through the input protection diodes.
Edit: Rough schematic showing supervisor chip ADM803/ADX803, you may want to add a power-on LED or resistor from Vdd to GND to help discharge the 5V faster so it resets reliably on a short power interruption.