In this example, I'm experiencing a strange issue:
1. [PROBLEM] When a breakpoint is put on app/main.c:44, GDB stops at the breakpoint, when I "continue" it continues and and never reaches to app/main.c:44 again, the application "crashes". I would expect GDB to stop at the same line, 10ms after I "continue"d.
2. If I comment out the "chThdSleepMilliseconds(10);" line and put a breakpoint to app/main.c:52 (for example), debugger reaches to the breakpoint. When I continue, it immediately reaches the same line as expected.
3. If I load the code directly with "make write", application works regardless the "chThdSleepMilliseconds(10);" line (44) is commented out or not.
If I change the target hardware from STM32F030 to STM32F103 and connect the appropriate board, everything works as expected. (GDB stops at line 44 while "chThdSleepMilliseconds(10);" line isn't commented out.)
What might be the cause of the [PROBLEM]?
chThdSleepX stucks while debugging on STM32F030x4 Topic is solved
Moderators: RoccoMarco, barthess
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: chThdSleepX stucks while debugging on STM32F030x4
Hi,
Try disabling tickless mode in chconf.h. Do you see the same problem?
Giovanni
Try disabling tickless mode in chconf.h. Do you see the same problem?
Giovanni
Re: chThdSleepX stucks while debugging on STM32F030x4
Hi Giovanni,
Setting CH_CFG_ST_TIMEDELTA to zero didn't help in the first attempt and then, it magically started working as expected while debugging. Currently leaving CH_CFG_ST_TIMEDELTA as is has no effect.
It turns out the original code works without any modification but needs an interesting trick. The problem that I originally described is reproducible all the time. However, a simple "restart gdb server" trick solves the problem. Here is the steps to solution:
1. Run GDB server on a terminal (as usual) (make start-gdb-server)
2. Run GDB client on another terminal (make debug-with-cmd)
3. See the debugger hits the line app/main.c:29 (halInit();). Press "c" to continue
4. See the debugger hits the line app/main.c:44 (chThdSleepMilliseconds(10);). Press "c" to continue
5. See the debugger (and the app crashes) (no breakpoint hits from now on)
6. Press Ctrl+C to see gdb prompt
7. "restart-server"
8. Press "c" to continue
9. See the debugger hits both line app/main.c:44 and app/main.c:52 (interestingly gdb hits line:52 twice everytime, but it doesn't hurt. does it?)
I'm not sure what goes on under the hood, but I should add that that restarting GDB triggers a negative pulse on the NRST pin (verified by myself with a logic analyzer) (which is currently connected to the MCU). Removing the NRST wire makes above trick useless.
(Note: Please use this version if you want to. Code remains same, only "mcu-debug" tool is updated and instructions are improved)
Setting CH_CFG_ST_TIMEDELTA to zero didn't help in the first attempt and then, it magically started working as expected while debugging. Currently leaving CH_CFG_ST_TIMEDELTA as is has no effect.
It turns out the original code works without any modification but needs an interesting trick. The problem that I originally described is reproducible all the time. However, a simple "restart gdb server" trick solves the problem. Here is the steps to solution:
1. Run GDB server on a terminal (as usual) (make start-gdb-server)
2. Run GDB client on another terminal (make debug-with-cmd)
3. See the debugger hits the line app/main.c:29 (halInit();). Press "c" to continue
4. See the debugger hits the line app/main.c:44 (chThdSleepMilliseconds(10);). Press "c" to continue
5. See the debugger (and the app crashes) (no breakpoint hits from now on)
6. Press Ctrl+C to see gdb prompt
7. "restart-server"
8. Press "c" to continue
9. See the debugger hits both line app/main.c:44 and app/main.c:52 (interestingly gdb hits line:52 twice everytime, but it doesn't hurt. does it?)
I'm not sure what goes on under the hood, but I should add that that restarting GDB triggers a negative pulse on the NRST pin (verified by myself with a logic analyzer) (which is currently connected to the MCU). Removing the NRST wire makes above trick useless.
(Note: Please use this version if you want to. Code remains same, only "mcu-debug" tool is updated and instructions are improved)
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: chThdSleepX stucks while debugging on STM32F030x4
Probably it resets peripheral states, applications assume that the MCU is in its post-reset state.
Giovanni
Giovanni
-
- Posts: 77
- Joined: Sat Mar 19, 2016 8:07 pm
- Been thanked: 17 times
Re: chThdSleepX stucks while debugging on STM32F030x4
Do you activate any powersaving mode in the idle thread or somewhere else?
CH_CFG_IDLE_ENTER_HOOK() is usually used to do that now, IIRC it was CORTEX_ENABLE_WFI_IDLE in previous versions of Chibios.
When you enter any kind of sleep mode, it can do weird things with the debugger connection. There are flags in some system register to disable this behavior and keep the debugger active, but you'll have to look those up in the reference manual and enable them during initialization, before the sleep code has a chance to run.
CH_CFG_IDLE_ENTER_HOOK() is usually used to do that now, IIRC it was CORTEX_ENABLE_WFI_IDLE in previous versions of Chibios.
When you enter any kind of sleep mode, it can do weird things with the debugger connection. There are flags in some system register to disable this behavior and keep the debugger active, but you'll have to look those up in the reference manual and enable them during initialization, before the sleep code has a chance to run.
Re: chThdSleepX stucks while debugging on STM32F030x4
electronic_eel wrote:Do you activate any powersaving mode in the idle thread or somewhere else?
No, I do nothing consciously. CH_CFG_IDLE_ENTER_HOOK is empty, as it can be seen here.
Re: chThdSleepX stucks while debugging on STM32F030x4
Above trick (restarting GDB) is unnecessary since this commit because apparently there is "monitor jtag_reset" command available. Adding this "reset" command inside "reload" command made this issue almost invisible since it resets the board on every "reload".
However, it seems like there is something puzzling here. Do you think it would be useful to provide an SSH connection with this STM32F030F4 board attached physically? I can setup a RaspberryPi for this purpose.
However, it seems like there is something puzzling here. Do you think it would be useful to provide an SSH connection with this STM32F030F4 board attached physically? I can setup a RaspberryPi for this purpose.
-
- Posts: 483
- Joined: Sat Nov 19, 2011 6:47 pm
- Location: Le Mans, France
- Has thanked: 21 times
- Been thanked: 30 times
Re: chThdSleepX stucks while debugging on STM32F030x4
if you use tickless mode with TIM2 (default) you need:
in your boardInit function.
This will stop TIM2 when debugging. Replace with alternate timer name if needed.
You also need this to debug while sleeping: (ie: WFI mode)
Code: Select all
DBGMCU->APB1FZ |= DBGMCU_APB1_FZ_DBG_TIM2_STOP;
in your boardInit function.
This will stop TIM2 when debugging. Replace with alternate timer name if needed.
You also need this to debug while sleeping: (ie: WFI mode)
Code: Select all
DBGMCU->CR |= DBGMCU_CR_DBG_SLEEP;
DBGMCU->CR |= DBGMCU_CR_DBG_STOP;
Re: chThdSleepX stucks while debugging on STM32F030x4
Hi mobyfab
I used "DBGMCU->APB1FZ |= DBGMCU_APB1_FZ_DBG_TIM3_STOP;" as I'm using TIM_3 as System Timer. However, when I disconnect the NRST pin from the debugger, this setup doesn't work as expected (It only reaches first breakpoint, when I continue it stucks).
Here is the reproduction steps:
1. Make sure that you have stlink in your path. (See requirements)
2. Get the example from try-fix-debugger-stuck branch:
3. Attach the STM32F030x4 board physically, but DO NOT connect the NRST pin to the debugger.
4. Start debugging: "make start-debugging"
5. See GDB hits the breakpoint on app/main.c:43
6. Continue with "c"
7. See you can't hit a breakpoint from now on.
If you want to experience the expected behaviour,
8. Connect the NRST pin to your debugger
9. gdb> Ctrl+C
10. gdb> reload
11. gdb> c
12. See GDB hits breakpoint on app/main.c:43 periodically.
You can visit try-fix-debugger-stuck branch. The hardware related files are in hw/ directory and board specific files are in hw/f030x4-custom-breakout/ directory.
I used "DBGMCU->APB1FZ |= DBGMCU_APB1_FZ_DBG_TIM3_STOP;" as I'm using TIM_3 as System Timer. However, when I disconnect the NRST pin from the debugger, this setup doesn't work as expected (It only reaches first breakpoint, when I continue it stucks).
Here is the reproduction steps:
1. Make sure that you have stlink in your path. (See requirements)
2. Get the example from try-fix-debugger-stuck branch:
Code: Select all
git clone --single-branch --branch try-fix-debugger-stuck --recursive https://github.com/ceremcem/chibi-examples2
3. Attach the STM32F030x4 board physically, but DO NOT connect the NRST pin to the debugger.
4. Start debugging: "make start-debugging"
5. See GDB hits the breakpoint on app/main.c:43
6. Continue with "c"
7. See you can't hit a breakpoint from now on.
If you want to experience the expected behaviour,
8. Connect the NRST pin to your debugger
9. gdb> Ctrl+C
10. gdb> reload
11. gdb> c
12. See GDB hits breakpoint on app/main.c:43 periodically.
You can visit try-fix-debugger-stuck branch. The hardware related files are in hw/ directory and board specific files are in hw/f030x4-custom-breakout/ directory.
Re: chThdSleepX stucks while debugging on STM32F030x4 Topic is solved
Today the example code didn't run in anyway (with or without debugging). I traced the execution and it turns out it doesn't make a context switch after stepping into chThdSleepX() function. I switched to stable_19.1 branch to take my chances and luckily it produced the following warnings:
I switched to GCC 4.9.2 and there is no issue at the moment with stable_18.2.x branch (see dependencies.txt).
Code: Select all
/home/ceremcem/ChibiOS/os/common/ports/ARMCMx/chcore_v6m.h:132:2: warning: #warning "This compiler has a know problem with Cortex-M0, see bugs: 88167, 88656." [-Wcpp]
I switched to GCC 4.9.2 and there is no issue at the moment with stable_18.2.x branch (see dependencies.txt).
Last edited by ceremcem on Mon Mar 18, 2019 1:09 pm, edited 1 time in total.
Who is online
Users browsing this forum: No registered users and 17 guests