ChibiOS Free Embedded RTOS

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]?

Hi,

Try disabling tickless mode in chconf.h. Do you see the same problem?

Giovanni

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)

Probably it resets peripheral states, applications assume that the MCU is in its post-reset state.

Giovanni

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.

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.

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.

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)

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.

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).