Not all critical exceptions can be trapped inside Default_Handler (or more specific error handler) - in some cases the CPU will be stopped immediately. Please navigate to "Quick access" box in the top-right corner and type in "Fault Status". Select this widget from the list and it should be added to your debug perspective. It will help you determine the cause of the exception by investigating fault status registers on the Cortex M core.

The code never goes to this line and when I pause the debug session, the program is often stuck at the first while in the OW_reset_pulse function. That's strange, the while loop check if timerOW is less than 480 BUT I can see the value of this variable and it stays in the loop altough timerOW's value is often between 1000 and 10000...

As far as I see, this variable is incremented in the timer callback, which is called from the timer ISR. The timer's period is quite small (1 us), so I suppose that's why you observe values larger than 480 after the loop.

Have you tested the application with the device attached to 1Wire output? I see the application expects some kind of response/acknowledgement.

The problem is not that i observe values larger than 480, it's that even if the values are greater than 480, the program stays in the loop !
So, there is no possible acknowledgement from another device because nothing is sent. The program just stays in the first while loop which checks the value of timerOW;

The default optimization level -O2 allows the compiler to optimize routines, variables etc. For debugging purposes the recommended optimization level is -O0 or -Og, as these will get the most meaningful information.

No, it doesn't mean it won't work in release mode. If you observe different behaviour between -O2 and -O0 optimization levels, there might be some synchronization issues in the source code (as the -O2 code usually runs 'faster').