Skip to content

Conversation

jnohlgard
Copy link
Member

@jnohlgard jnohlgard commented Oct 6, 2017

The main goal of this PR is to reduce code duplication (look how many openocd.cfg files are almost identical in the repo). The unification of the debugger interface Makefiles will also make the debugger selection via USB serial number string available to all boards, instead of having different kludges in each board Makefile.
A secondary goal is to allow using any supported debug interface adapter (JTAG/SWD adapters etc.) to debug any supported board. This is especially useful when working with custom boards without integrated debug adapter or development boards which are installed in things where the original debug adapter connection (USB port) is physically inaccessible, but a JTAG header is available.

New environment variables for selecting debug adapter:

  • DEBUG_ADAPTER: select which type of debugger should be used for flash programming and for debugging
  • DEBUG_ADAPTER_ID: Use this identification to select which programmer to use when more than one device is connected to the same host machine. This is usually the USB serial number, found from list-ttys.sh or lsusb -v, but it is implementation specific to each debug adapter type.

So far only Segger J-Link, CMSIS DAP, and Eistec Mulle are supported via the DEBUG_ADAPTER_ID selection

TODO:

  • ST-Link adapter configuration
  • ...

Depends on #7685

Testing status:

  • airfy-beacon
  • arduino-atmega-common
  • arduino-due
  • arduino-duemilanove
  • arduino-mega2560
  • arduino-mkr1000
  • arduino-mkr-common
  • arduino-mkrzero
  • arduino-uno
  • arduino-zero
  • avsextrem
  • b-l072z-lrwan1
  • calliope-mini
  • cc2538dk
  • cc2650-launchpad
  • cc2650stk
  • chronos
  • ek-lm4f120xl
  • f4vi1
  • fox
  • frdm-common
  • frdm-k22f
  • frdm-k64f
  • frdm-kw41z
  • iotlab-a8-m3
  • iotlab-common
  • iotlab-m3
  • limifrog-v1
  • maple-mini
  • mbed_lpc1768
  • microbit
  • mips-malta
  • msb-430
  • msb-430-common
  • msb-430h
  • msba2
  • msba2-common
  • msbiot
  • mulle
  • native
  • nrf51dongle
  • nrf52dk
  • nrf6310
  • nrf52840dk
  • nucleo32-common
  • nucleo32-f031
  • nucleo32-f042
  • nucleo32-f303
  • nucleo32-l031
  • nucleo32-l432
  • nucleo144-common
  • nucleo144-f207
  • nucleo144-f303
  • nucleo144-f412
  • nucleo144-f413
  • nucleo144-f429
  • nucleo144-f446
  • nucleo144-f722
  • nucleo144-f746
  • nucleo144-f767
  • nucleo-common
  • nucleo-f030
  • nucleo-f070
  • nucleo-f072
  • nucleo-f091
  • nucleo-f103
  • nucleo-f302
  • nucleo-f303
  • nucleo-f334
  • nucleo-f401
  • nucleo-f410
  • nucleo-f411
  • nucleo-f446
  • nucleo-l053
  • nucleo-l073
  • nucleo-l152
  • nucleo-l476
  • nz32-sc151
  • opencm904
  • openmote-cc2538
  • pba-d-01-kw2x
  • pca10000
  • pca10005
  • pic32-clicker
  • pic32-wifire
  • qemu-i386
  • remote-common
  • remote-pa
  • remote-reva
  • remote-revb
  • samd21-xpro
  • saml21-xpro
  • samr21-xpro
  • seeeduino_arch-pro
  • slwstk6220a
  • sodaq-autonomo
  • spark-core
  • stm32f0discovery
  • stm32f3discovery
  • stm32f4discovery
  • stm32f7discovery
  • telosb
  • udoo
  • waspmote-pro
  • wsn430-common
  • wsn430-v1_3b
  • wsn430-v1_4
  • x86-multiboot-common
  • yunjia-nrf51822
  • z1

@jnohlgard jnohlgard added Type: cleanup The issue proposes a clean-up / The PR cleans-up parts of the codebase / documentation Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation Area: build system Area: Build system Area: tools Area: Supplementary tools labels Oct 6, 2017
@jnohlgard jnohlgard added the State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet label Oct 6, 2017
@jnohlgard jnohlgard force-pushed the pr/board-debugger-separation branch 2 times, most recently from 891fec2 to 4df35d2 Compare October 8, 2017 06:17
@jnohlgard
Copy link
Member Author

Refactored USB serial handling for the edbg tool to match openocd

@jnohlgard jnohlgard force-pushed the pr/board-debugger-separation branch 2 times, most recently from 44294cd to cd9bb85 Compare October 11, 2017 13:53
@jnohlgard jnohlgard added the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Oct 11, 2017
@jnohlgard
Copy link
Member Author

  • All board Makefiles updated
  • All Nucleo OpenOCD configurations merged
  • Fixed some typos
  • Removed adapter configuration from all OpenOCD configurations

@jnohlgard jnohlgard added the State: waiting for other PR State: The PR requires another PR to be merged first label Oct 11, 2017
@jnohlgard jnohlgard force-pushed the pr/board-debugger-separation branch from a34a166 to a09c3ef Compare October 13, 2017 08:39
@jnohlgard
Copy link
Member Author

I would very much like this PR to be merged early in the next release cycle to avoid having to rebase this for every new board`that is added during the cycle. @kYc0o Do you think you will have time to review this during next two weeks?

@jnohlgard jnohlgard added Discussion: RFC The issue/PR is used as a discussion starting point about the item of the issue/PR and removed State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet labels Oct 13, 2017
@jnohlgard jnohlgard changed the title [WIP] boards: board<->debugger separation RFC: boards: board<->debugger separation Oct 13, 2017
@kYc0o
Copy link
Contributor

kYc0o commented Oct 13, 2017

Yes! I need it for my OTA stuff, expect a review very soon!

@jnohlgard jnohlgard force-pushed the pr/board-debugger-separation branch 2 times, most recently from 81c5d3e to 47a2acc Compare October 19, 2017 14:13
@jnohlgard jnohlgard removed the State: waiting for other PR State: The PR requires another PR to be merged first label Oct 19, 2017
@jnohlgard
Copy link
Member Author

rebased after dependency was merged

@kYc0o
Copy link
Contributor

kYc0o commented Oct 19, 2017

Thanks for rebasing.

I think the commit list is quite long. Can you maybe add only one commit for all the boards? The change is the same so I think a commit is enough and self-explanatory.

Copy link
Contributor

@kYc0o kYc0o left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well this seems to improve the situation mostly for "common" boards, like nucleo or kinetis. However I don't see too much improvement when the files were moved (and simplified, that's nice) from the board directory to the common one.

Is there maybe a way to get rid completely of the config files and (even if it's somehow ugly) unify the definitions in a single file?


source [find target/stm32f4x.cfg]

reset_config srst_only
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you explain this change?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I copied the stm32f4discovery board configuration and stripped the interface configuration.
http://repo.or.cz/openocd.git/blob/refs/heads/master:/tcl/board/stm32f4discovery.cfg

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately I don't have the board to test it, but I observed this change somewhere else. I will try to test it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The stm32 discovery boards have the same kind of change, if you have any of those?

sh -c "${OPENOCD} -f '${OPENOCD_CONFIG}' \
sh -c "${OPENOCD} \
${OPENOCD_ADAPTER_INIT} \
-f '${OPENOCD_CONFIG}' \
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't possible to factorise these 3 repeated commands?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm, I don't see the benefit of concatenating three variables into one when it's only in 3-4 places. It would make the script less readable though in my opinion.

@@ -3,6 +3,14 @@ EDBG ?= $(RIOT_EDBG)
FLASHER ?= $(EDBG)
OFLAGS ?= -O binary
HEXFILE = $(ELFFILE:.elf=.bin)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Haven't this already been fixed in the previous PR? Or it was only done for OpenOCD?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oops, this should be IMAGE_FILE

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm, actually, it's still HEXFILE because that is the target of the OBJCOPY make rule

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, it's just that it looks wrong and needs to be fixed. I wouldn't mind to fix it in this PR but if you prefer it can be a following PR.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer to keep this PR focused on separating the openocd configuration from the board Makefiles and do any other improvements in separate pulls.

@jnohlgard
Copy link
Member Author

It would be possible to remove the configuration files completely for some of the boards by introducing something at the CPU level for a default basic config. Some boards may need some more elaborate configuration so it won't eliminate them completely.
I suggest we do that in a separate PR though, to keep this one clean and to the point.

@jnohlgard
Copy link
Member Author

ping @kYc0o
Do you have any of the st-link boards available?

@kYc0o
Copy link
Contributor

kYc0o commented Nov 7, 2017

Oops, sorry, this slipped in the queue. Yes, I have some ST-Link boards, I'll test asap.

@jnohlgard jnohlgard removed the Discussion: RFC The issue/PR is used as a discussion starting point about the item of the issue/PR label Nov 7, 2017
@jnohlgard jnohlgard changed the title RFC: boards: board<->debugger separation boards: board<->debugger separation Nov 7, 2017
@kYc0o
Copy link
Contributor

kYc0o commented Nov 7, 2017

I guess testing most of the adaptors should be enough?

@jnohlgard
Copy link
Member Author

Yes, I don't think we need to test all boards for this.

@kYc0o
Copy link
Contributor

kYc0o commented Nov 7, 2017

For mulle I have this:

embedded:startup.tcl:60: Error: Can't find /Users/facosta/git/RIOT2/RIOT/board/mulle/dist/openocd/mulle-programmer-0.70.cfg

Otherwise I still don't like the things about HEXFILE. When I use JLink I have this:

### Flashing Target ###
### Flashing at address 0x0 ###
HEXFILE found

which should use an ELF file...

@jnohlgard jnohlgard force-pushed the pr/board-debugger-separation branch from 34eee31 to 89b1214 Compare November 10, 2017 09:51
@jnohlgard
Copy link
Member Author

@kYc0o fixed typo in the openocd config file name for mulle. Will test this PR with actual mulle programmer hardware later today.

@jnohlgard
Copy link
Member Author

@kYc0o this PR does not touch the jlink.sh script (JLinkGDBServer launcher), it only touches the boards which use a jlink adapter with openocd.sh.

@jnohlgard
Copy link
Member Author

@kYc0o A suggestion for a future improvement is to implement some kind of debug tool selection, like DEBUG_TOOL=openocd for using openocd.sh or DEBUG_TOOL=jlink for JLinkGDBServer. Others are also possible, like DEBUG_TOOL=avrdude. But this PR is large enough already in my opinion, and I don't have any experience with those other tools, only openocd.

@jnohlgard jnohlgard force-pushed the pr/board-debugger-separation branch 2 times, most recently from 6bbd902 to c045198 Compare November 13, 2017 13:58
@kYc0o
Copy link
Contributor

kYc0o commented Nov 15, 2017

Tested and working on mulle.

Copy link
Contributor

@kYc0o kYc0o left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK. Please squash.

@jnohlgard jnohlgard force-pushed the pr/board-debugger-separation branch from c045198 to 6ccbf07 Compare November 15, 2017 19:11
@jnohlgard
Copy link
Member Author

squashed, need to check if there have been any new boards since last rebase..

@jnohlgard
Copy link
Member Author

Added a config change for the bluepill board which was added after this PR was opened.

# programmer board serial number.

# Fall back to PROGRAMMER_SERIAL for backwards compatibility
export DEBUG_ADAPTER_ID ?= $(PROGRAMMER_SERIAL)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know if for this just an announce that it changed would be enough... but let's keep it for now...

@kYc0o
Copy link
Contributor

kYc0o commented Nov 16, 2017

Murdock agreed, please squash again.

Joakim Nohlgård added 3 commits November 17, 2017 10:03
Attempt to decouple board configuration from debugger interface
configuration by specifying the DEBUG_IFACE variable for the debug
hardware interface to use.
@jnohlgard jnohlgard force-pushed the pr/board-debugger-separation branch from 2d90c52 to f4e9cad Compare November 17, 2017 09:03
@jnohlgard
Copy link
Member Author

squashed

@kYc0o
Copy link
Contributor

kYc0o commented Nov 17, 2017

Excellent! Then go!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: build system Area: Build system Area: tools Area: Supplementary tools CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Type: cleanup The issue proposes a clean-up / The PR cleans-up parts of the codebase / documentation Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants