EBlink override the default halt on Reset_Handler

[Mate]

Dear EmBitz,
I have one custom Bootloader project which is performing a runtime software Restart: NVIC_SystemReset(); on STM32 (tried on different families: F1, F4 and F0).
While debuggins session is running EmBitz stops the CPU at Reset_Handler eventough there are no breakpints and inside the debug interface settings all relevant options are unchecked (See images in attachments).
I Would expect that the poper behavior would be that the CPU doesn't stop after executing NVIC_SystemReset(); (like it was on the EmBitz 1.11).

Note: I am using:
- Embitz 2.62 
- EBlink 5.13 (Build 193)
- Win11
- ST Link V2

Best Regards,
Mate

[embitz]

Make a small F4 project for me and I will see if I can fix it.

Update:
I think this is because the reset flag is set and catched by EBlink. Are you sure that it was working with the old STlinkGDB?

A workaround that I use for my bootloaders is using a jump/call to the reset factor in debug mode.

[Mate]

Make a small F4 project for me and I will see if I can fix it.
Update:
I think this is because the reset flag is set and catched by EBlink. Are you sure that it was working with the old STlinkGDB ?
A workaround that I use for my bootloaders is using a jump/call to the reset factor in debug mode.

Hi,
thank you for your fast response.
I have zipped a small STM32F4 project with one "wait loop" (takes 2-3seconds) followed by a reset call.

I am still using EmBitz 1.11, and I wanted to transfer all my projects to the new EmBitz, and was investigating this yesterday. Yes, on Embitz 1.11 with STlinkGDB the CPU doesn't stop after the restart. 

Unfortunately, the workaround (just jumping to the reset vector) would not work for me, because it doesn't reset the MCU peripherals.
This fix would be very important to me, thank you once more.

Best Regards,
Mate

[embitz]

Ok, I have a version where this is solved but I'm not sure I like it enough.
The problem is that if an accidental resets occur, we don't notice this anymore. I'm not sure how to handle this.

[embitz]

Perhaps an solution would be if fault unwind level 2 will stop the target and level lower will just reset the target. Perhaps with an dialog message on windows and only a notice text on linux.

[Mate]

Ok, I have a version where this is solved but I'm not sure I like it enough.
The problem is that if an accidental resets occur, we don't notice this anymore.  I'm not sure how to handle this.

If the user fears a reset, he/she could put a breakpoint on reset handler. Should this work? Otherwise it could be great to give a user a possibility to choose to detect or not detect a reset (maybe a checkbox in the debug interface options dialog).

---

Perhaps an solution would be if fault unwind level 2 will stop the target and level lower will just reset the target. Perhaps with an dialog message on windows and only a notice text on linux.

Not sure if I understand this correctly, because I am not so into how the EbLink is coded, but I would suggest to make this setting independent of other settings if it is possible...

[embitz]

I'm not that fond of checkboxes for everything. I think I have a workable solution.

You have to chose Fault unwind level "forced only" or "off". If the unwind level is "Auto break" a dialog screen will popup in windows and the program stops at the reset vector.  The other unwind level will only show a message on the terminal (or in the EBlink log pane of EB). In linux both times a message will be shown on terminal.

I think that you also need a newer set of EBlink script files. Just get them from github or install the latest binary and replace the EBlink.exe

This is an unsigned test version

[Mate]

I'm not that fond of checkboxes for everything. I think I have a workable solution.

You have to chose Fault unwind level "forced only" or "off". If the unwind level is "Auto break" a dialog screen will popup in windows and the program stops at the reset vector.  The other unwind level will only show a message on the terminal (or in the EBlink log pane of EB). In linux both times a message will be shown on terminal.

I think that you also need a newer set of EBlink script files. Just get them from github or install the latest binary and replace the EBlink.exe

This is an unsigned test version

Thank you, this seems to be working, can you please describe what does the functionality of the "Fault unwind level"? Is it somwhere described? Does changing this have some side effects?

[embitz]

Fault unwind is a build-in feature to catch runtime errors, it will unwind the stack and inform the user about the exception and additional info. By unwinding the stack, the debugger is halted on the line with the error or with a meaningful call stack in case of instruction errors. You can simple click in the callstack windows on the caller and see where the fault is.

Level 0 = Fault unwind disabled
Level 1 = Not active but unwind is Forced on (user) halt if any errors are detected
Level 2 = the code will be actively halted when an error occurs

As soon as I have some time left I will post a "howto" with runnable code examples to demonstrate Fault unwind