openocd: Use reset halt when starting debug-server by jnohlgard · Pull Request #10479 · RIOT-OS/RIOT

jnohlgard · 2018-11-27T14:46:01Z

Contribution description

Makes the debug-server start up more robust, especially when combined with reset_config connect_assert_srst in the OpenOCD configuration.

Testing procedure

With any board with an onboard debugger interface and using OpenOCD:

make debug-server

Verify that the OpenOCD instance can connect to the board and that the application running is halted (e.g. does not respond to UART shell commands anymore, software controlled LEDs stop blinking etc.)

in a different terminal:

make debug

(This will attempt to start another instance of openocd, but that will fail since the same UDP port is already used by the running debug-server instance)

See that GDB works as expected:

continue

Verify that the application is running.

Press CTRL+C in GDB, verify that GDB has managed to halt the application.

Issues/PRs references

aabadie · 2018-11-27T15:09:28Z

dist/tools/openocd/openocd.sh

            -c 'init' \
            -c 'targets' \
-            -c 'halt'"
+            -c 'reset halt'"


Instead of this, maybe we could reuse ${OPENOCD_DBG_START_CMD} like in do_debug. This allows boards requiring this to override start command.

jnohlgard · 2018-11-27T22:08:32Z

Modified to reuse OPENOCD_DBG_START_CMD for both debug and debug-server. Changed the default command to be reset halt instead of only halt

aabadie · 2018-11-28T07:25:55Z

dist/tools/openocd/openocd.sh

 # the target when starting a debug session. 'reset halt' can also be used
 # depending on the type of target.
-: ${OPENOCD_DBG_START_CMD:=-c 'halt'}
+: ${OPENOCD_DBG_START_CMD:=-c \'reset halt\'}


This needs to be discussed a bit more. See #8976 where I tried to set this default to boards using st-link.
The problem with this change is that by default one cannot attach to the current state of a running application.

Makes the OpenOCD start up more robust, especially when combined with reset_config connect_assert_srst in the target configuration.

'reset halt' is now the default value for OpenOCD

aabadie · 2019-03-14T09:39:35Z

To move forward on this, I allowed myself to rebase this PR and slightly update it: variable documentation is updated in openocd.sh and the default value used for this variable in a some boards (f1 based + b-l072Z-lrwan1 boards) is removed from the makefile, since now it's using the openocd default value.

@cladmi, are you interested in having a look ?

cladmi · 2019-03-14T13:04:22Z

I can try on a few boards indeed.

Is this saying we are indeed going toward putting connect_assert_srst by default ?
I have some waiting commits to enable it on some boards https://github.com/RIOT-OS/RIOT/pull/10870/commits
If you have an easy way (even arch specific) to put a board into a non flashable mode without this option, I would gladly add a test for it. I know the tests/driver_adt7310 test was a good one to break some of the mentioned boards.

kaspar030 · 2019-03-14T13:12:17Z

This means running "make debug" would always reset a board? do we want that?

I sometimes realize a board is stuck somewhere, then connect the debugger to see where it got stuck.

aabadie · 2019-03-14T13:20:05Z

This means running "make debug" would always reset a board? do we want that?

By default yes, but one can still have the non reset behaviour by passing OPENOCD_DBG_START_CMD="-c 'halt'" to the command line.

cladmi · 2019-03-14T13:26:12Z

@kaspar030 currently there are many cases where doing make flash does not flash because the CPU is in an un-handled state. This breaks all testing possibilities and I would put it with a bigger priority even if our default configuration also resets when debugging.

kaspar030 · 2019-03-14T13:28:40Z

@kaspar030 currently there are many cases where doing make flash does not flash because the CPU is in an un-handled state.

Then add the corresponding reset halt to the flash command. I don't understand what that has to do with starting the gdb server.

aabadie · 2019-03-14T14:22:31Z

There is a confusion here. This PR is just about debug. Having reset halt before starting the debug-server fixes gdb connection when connect_assert_srst is used by the openocd configuration. This option is useful when the CPU is in sleep mode (otherwise OpenOCD is not able to reflash it without manual interaction)

fjmolinas · 2020-01-03T19:22:00Z

Is this one still relevant? with OPENOCD_RESET_USE_CONNECT_ASSERT_SRST there is no issue when launching make debug, @aabadie do you agree?

fjmolinas · 2020-01-09T09:35:24Z

ping @aabadie!

leandrolanzieri · 2020-03-13T07:37:49Z

ping!

benpicco · 2020-04-01T09:17:14Z

I agree with @kaspar030 here. I too will use make debug to see where the code got stuck, the default behavior shouldn't be to reset the CPU here.

If you want to start debugging in a defined state, how about adding a reset-debug target instead?

stale · 2020-10-10T11:23:29Z

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

jnohlgard added Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Area: tools Area: Supplementary tools labels Nov 27, 2018

jnohlgard added this to the Release 2019.01 milestone Nov 27, 2018

jnohlgard requested a review from aabadie November 27, 2018 14:46

aabadie reviewed Nov 27, 2018

View reviewed changes

jnohlgard force-pushed the openocd/debug-server-reset branch from 4d65bbd to 761726d Compare November 27, 2018 22:07

aabadie reviewed Nov 28, 2018

View reviewed changes

This was referenced Nov 29, 2018

dist/tools/openocd: use reset halt command for board using stlink #8976

Closed

boards/stm32l0: Fix openocd to prevent flash locking #10343

Merged

aabadie modified the milestones: Release 2019.01, Release 2019.04 Jan 25, 2019

aabadie force-pushed the openocd/debug-server-reset branch from 761726d to 731cdcd Compare March 14, 2019 09:23

openocd: Use reset halt when starting GDB server

df08a86

Makes the OpenOCD start up more robust, especially when combined with reset_config connect_assert_srst in the target configuration.

aabadie force-pushed the openocd/debug-server-reset branch from 731cdcd to df08a86 Compare March 14, 2019 09:28

boards: remove useless default OPENOCD_DBG_START_CMD

93ef8b9

'reset halt' is now the default value for OpenOCD

aabadie self-requested a review March 15, 2019 06:48

miri64 modified the milestones: Release 2019.04, Release 2019.07 May 7, 2019

MrKevinWeiss modified the milestones: Release 2019.07, Release 2019.10 Jul 16, 2019

fjmolinas mentioned this pull request Aug 7, 2019

dist/tools/openocd: add OPENOCD_EXTRA_INIT_RESET use for nucleo-f091rc #11976

Merged

kb2ma modified the milestones: Release 2019.10, Release 2020.01 Oct 9, 2019

fjmolinas modified the milestones: Release 2020.01, Release 2020.04 Jan 15, 2020

leandrolanzieri removed this from the Release 2020.04 milestone Apr 8, 2020

stale bot added the State: stale State: The issue / PR has no activity for >185 days label Oct 10, 2020

stale bot closed this Nov 11, 2020

Conversation

jnohlgard commented Nov 27, 2018

Contribution description

Testing procedure

Issues/PRs references

Uh oh!

aabadie Nov 27, 2018

Choose a reason for hiding this comment

Uh oh!

jnohlgard commented Nov 27, 2018

Uh oh!

aabadie Nov 28, 2018

Choose a reason for hiding this comment

Uh oh!

aabadie commented Mar 14, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cladmi commented Mar 14, 2019

Uh oh!

kaspar030 commented Mar 14, 2019

Uh oh!

aabadie commented Mar 14, 2019

Uh oh!

cladmi commented Mar 14, 2019

Uh oh!

kaspar030 commented Mar 14, 2019

Uh oh!

aabadie commented Mar 14, 2019

Uh oh!

fjmolinas commented Jan 3, 2020

Uh oh!

fjmolinas commented Jan 9, 2020

Uh oh!

leandrolanzieri commented Mar 13, 2020

Uh oh!

benpicco commented Apr 1, 2020

Uh oh!

stale bot commented Oct 10, 2020

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

10 participants

aabadie commented Mar 14, 2019 •

edited

Loading