Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[tools] Refactor tooling and add JLink support #965

Merged
merged 3 commits into from Mar 7, 2023

Conversation

salkinium
Copy link
Member

@salkinium salkinium commented Feb 25, 2023

Cleaned up modm_tools and the Scons wrappers for it a little, and added JLink support.
For our purposes OpenOCD is still better and much more configurable, however, JLink tends to have more device coverage and adds new devices faster. It can also be faster for certain tasks like RTT and uploading.

  • Refactored modm_tools:
    • Added missing gdbinit functions for BMP and JLink
    • Moved SCons logging wrapper into openocd wrapper where it belongs
    • Added SCons env.SubstList() to listify, aggregate and substitute environment variables
    • Using a contextmanager for the backend to simplify code
    • Simplify SCons with env.AlwaysBuildAction
    • Split log into rtt.py and itm.py and clean up options.
    • Only compare-sections when using GDB in a UI mode
    • Properly call the code as a Python module to remove the sys.path hacks.
  • Added JLink support
    • Programming
    • Debugging via GDB
    • Reset
    • RTT
    • ITM via SWO
    • Documentation
      • Build
      • Scons
      • Make
      • Cmake
    • Build Systems Support
      • SCons
      • Make
      • CMake

@salkinium
Copy link
Member Author

Ok, this PR got a little out of hand. But I wanted to clean up modm_tools anyways in preparation for pulling it external and making it its own python module… Anyways, JLink is running not as stable as OpenOCD at least on macOS, kinda dissappointing tbh. I only tested the STLink->Jlink replacement and the JLink Mini EDU, perhaps the more expensive probes are better. Meh.

@rleh
Copy link
Member

rleh commented Feb 28, 2023

When you write jlink, you mean the combination of one of the J-Link (Edu/Base/Plus/Mini/Classic/...) debug probes (hardware device with USB connector from Segger) and the J-Link Tools (proprietary software blob from Segger), right?

The J-Link (or compatible, cheaply available as H-Link/...) USB dongle works fine with OpenOCD and supports a very large number of devices, e.g. Atmel/Microchip SAM.

@salkinium
Copy link
Member Author

When you write jlink, you mean the combination of one of the J-Link (Edu/Base/Plus/Mini/Classic/...) debug probes (hardware device with USB connector from Segger) and the J-Link Tools (proprietary software blob from Segger), right?

Yes, I use modm_tools for work and added jlink support, and am now contributing this back upstream again. J-Link generally has support for newer devices earlier than OpenOCD, otherwise I very much prefer OpenOCD, since it's way more configurable and also more stable than the J-Link proprietary software, at least on macOS.

I need to check if RTT performance is better as they claim, I vaguely remember that OpenOCD was only able to transfer single-digit kB/s range, because they drive everything from the USB Host, whereas J-Link should do it directly on the probe.

@salkinium salkinium force-pushed the feature/jlink branch 6 times, most recently from a17dd60 to ce1a01d Compare March 4, 2023 21:38
@salkinium salkinium added the ci:hal Triggers the exhaustive HAL compile CI jobs label Mar 4, 2023
@salkinium
Copy link
Member Author

Ok, so I've refactored a little more and the Makefile and CMake generator are now calling modm_tools via the module syntax, ie. python3 -m modm_tools.openocd [args]. This is in preparation for moving these tools into the modm package, that we currently only use for dependency grouping. It will then change to python3 -m modm.openocd [args], and there will be actual Python documentation rather than the Markdown hack that we have right now (tools.modm.io?).

- Call modm_tools as a Python module in the Makefile and CMake build systems.
- Simplify and refactor modm_tools code.
- Simplify SCons wrapper code around modm_tools.
- Split modm_tools/log.py into rtt.py and itm.py to separate argument parsers.
- Separate gdbinit files for each debug probe for correct reset command.
- Update and synchronize documentation.
@salkinium salkinium merged commit 241b0d1 into modm-io:develop Mar 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

None yet

2 participants