+- EmBitz (https://www.embitz.org/forum)
+-- Forum: EBlink (https://www.embitz.org/forum/forum-3.html)
+--- Forum: Development (https://www.embitz.org/forum/forum-11.html)
+--- Thread: EBlink override the default halt on Reset_Handler (/thread-209.html)
EBlink override the default halt on Reset_Handler - Mate - 06-11-2024
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
RE: EbLink stopping on the Reset_Handler even when it shouldn't - embitz - 06-11-2024
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.
RE: EbLink stopping on the Reset_Handler even when it shouldn't - Mate - 06-11-2024
(06-11-2024, 05:37 PM)embitz Wrote: 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
RE: EbLink stopping on the Reset_Handler even when it shouldn't - embitz - 06-11-2024
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.
RE: EbLink stopping on the Reset_Handler even when it shouldn't - embitz - 06-11-2024
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.
RE: EbLink stopping on the Reset_Handler even when it shouldn't - Mate - 06-11-2024
(06-11-2024, 08:31 PM)embitz Wrote: 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).
(06-11-2024, 08:34 PM)embitz Wrote: 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...
RE: EbLink stopping on the Reset_Handler even when it shouldn't - embitz - 06-11-2024
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
RE: EbLink stopping on the Reset_Handler even when it shouldn't - Mate - 06-11-2024
(06-11-2024, 09:35 PM)embitz Wrote: 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?
RE: EBlink override the default halt on Reset_Handler - embitz - 07-11-2024
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