tools/mspdebug: fix make debug and make debugserver
#19556
Conversation
maribu
added
Type: bug
maribu
force-pushed
the
tools/mspdebug
branch
4 times, most recently
from
2d7a19f
to
c7d8482
Compare
| ifeq ($(strip $(MSPDEBUG_PROGRAMMER)),uif) | ||
| MSPDEBUGFLAGS += -d $(PROG_DEV) | ||
| endif |
There was a problem hiding this comment.
Apparently it's possible to flash using mspdebug over a TTY, using uif-bsl (maybe before it was called uif ?). Even if unused (no msp430 based board supports this in RIOT codebase, maybe it was for msp430 boards that were removed a few years ago ?), maybe we should keep it for compatibility ?
There was a problem hiding this comment.
mspdebug supports flashing via TTY instead of USB for a number of programmers, but defaults to using USB. My guess is that this is a workaround that I don't think is needed anymore. At least judging from the output of mspdebug uif it seems it would just select the matching USB device directly without a TTY given:
$ mspdebug uif
MSPDebug version 0.25 - debugging tool for MSP430 MCUs
Copyright (C) 2009-2017 Daniel Beer <[email protected]>
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Chip info database from MSP430.dll v3.3.1.4 Copyright (C) 2013 TI, Inc.
usbutil: unable to find a device matching 0451:f430
But that theory will be difficult to put to test:
The MSP-FET430UIF is no longer recommended for new designs.
And it seems to not be available any more. I have the feeling that most people actually taking a look at MSP430 will either use the new boards with FRAM with the integrated eZ-FET programmer/debugger (once that is ported to RIOT), or go for Olimex hardware with legacy MSP430Fx1xx hardware. Maybe @OlegHahm has still legacy programmers at hands and could give it a test?
|
I could add the (E.g. for my Olimex MSP430-JTAG-TINY-V2 programmer I first had to write an udev rule to give my default user the permissions. If I had no root access to install such udev rule, I could have used the TTY interface instead.) |
maribu
force-pushed
the
tools/mspdebug
branch
2 times, most recently
from
344c8cd
to
dc0ef4f
Compare
|
|
|
I just noticed that |
The semantics of `make debug` and `make debugserver` have changed in the years since the MSP430 integration. This brings the implementation back into line with the current semantics - `make debug` now starts both mspdebug and GDB, no need to run `make debugserver` prior to `make debug` anymore - `make debug` no longer flashes the target to not waste flash erase cycles - GDB mutliarch support is added - support for selecting a debug adapter by its serial is added
|
bors merge |
|
Build succeeded! The publicly hosted instance of bors-ng is deprecated and will go away soon. If you want to self-host your own instance, instructions are here. If you want to switch to GitHub's built-in merge queue, visit their help page. |
|
Thx :) |
Contribution description
The semantics of
make debugandmake debugserverhave changed in the years since the MSP430 integration. This brings the implementation back into line with the current semanticsmake debugnow starts both mspdebug and GDB, no need to runmake debugserverprior tomake debuganymoremake debugno longer flashes the target to not waste flash erase cyclesTesting procedure
make BOARD=<SOME_MSP430_BOARD> debugshould now just work. (It does so for me and my Olimex MSP430-H1611.)Issues/PRs references
None