The road to DAPLink 0256 (and beyond)

[mathias-arm]

The road to DAPLink 0256 (and beyond)

It has now been more than two years since the last releases. Because of Windows 7 driver issues version 0254, which contained multiple new features, was discretely released on GitHub and at the time of writing is still not available on the public site. Version 0255 was a release dedicated to the BBC micro:bit v2.

The next version should be 0256.

What

A lot of the efforts for this new version have been spent on tasks that will not be visible to users, but should make a lot of difference for developers.

Compilers

The change that is probably going to define this release is the change in compilers supported, and most notably GCC (to be clear arm-none-eabi-gcc identified as gcc_arm) will now be supported. Given the amount of requests, it is likely be the most commonly used going forward.

ARMC5 (armcc) is being replaced by ARMC6 (armclang). We have heard from several people that they like the MDK tooling and the compilers often yield smaller binaries.

The current goal is that all three compilers will be able to build DAPLink 0256. There is one exception because armcc does not support Cortex-M33 cores. We hope, but do not make any commitment, that all projects will all actually work with the different compilers.

gcc_arm and armclang will be using RTX5 with the CMSIS RTOS2 API, while armcc will keep using RTOS1-based RTX4.

Build

For the build system we will be focusing on project-generator, deprecating the mbed-cli option. This is a lightweight cross-platform option that can help developers leverage their preferred environments.

New features

There are still a few new things that have been added since version 0254:

• 3 new HICs kl27z used in the Microbit:v2, m48ssidae used in several Nuvoton boards, lpc55xx used in the NXP MCU-Link.
• Many new boards.
• Many updates and fixes.

The lpc55xx is the first HIC to support JTAG and the second to support SWO. Those features could be added to other HICs, and there are pull requests to that effect. Additionally new HICs and boards could be added in time for the next release.

How

Branches

As many projects have done, the master branch will be renamed main, according to GitHub this should not too disruptive. We will make an announcement before making this change.

The experimental_compilers branch will be renamed develop. It will be merged to main before the 0256 release. At that point we could either:

• Go back to all development occurring on main.
• Continue using a main + develop branch policy, with development and PRs targeting develop and main will be used for releases.

Continuous Integration

You might have heard there was a big power outage in Texas this winter. The server running the Jenkins server driving the CI for DAPLink was hosted in Austin and did suffer a hardware failure as a result. This platform allowed to run DAPLink tests on different hardware and operating systems.

A new CI infrastructure is being planned, this time in Cambridge, UK. We also plan to address one important limitation the previous one had, which was that only maintainers could see the test results.

Already the support for GCC allows us to use GitHub Actions to do automated builds on Linux, MacOS and Windows.

Deprecating boards

Supports for many boards has been added over the project's lifetime. As a result a complete build in DAPLink creates 151
interface or bootloader binaries, of those 116 would be distributed using the current release process. The difference between those two numbers is because bootloaders are distributed separately, and not all interfaces projects are considered "supported".

We want to focus our attention in the most efficient way, so we are going to have to come up with some criteria to decide when to deprecate targets and the process to do so. One of the disadvantages of using github.io to distribute the binaries is that we don't have any metrics on which binaries are downloaded.

The process could be (those are just examples):

• The first step would be to stop making that binary part of the release process.
• The second step would be to move its build to be part of second tier not built on all CI tests.
• The third and last step would be to remove it (code and record) from the repository.

The criteria could be (those are just examples):

• Some form of evidence of volume or on-going popularity,
• Availability for purchase,
• Efforts needed to maintain (breakage, issues),
• Volunteer(s) to fix issues and perform tests on a on-going basis,
• etc.

Communication

We have started to use GitHub Discussions, which is much better for some things than issues. We are thinking about adding some form of chat, something a little bit less formal, with the risk of being less persistent. There are many options (Slack, Matrix, Zulip, Discord, IRC), we will have to weigh the pros and cons.

The future

DAPLink is already quite modular and customizable, but there are different initiatives that could help improve that:

• With the smaller HICs we are getting to the limits (RAM, Flash, etc.). New features simply will not fit, so we will need to offer the ability to pick and choose some features.

• Often the difference between two interface images are a few constants and the flash algo. Work has been done to make those differences a data-driven payload in the firmware. We could replace many compilation and linking operations with some binary post-processing (tools/post_process.py). In the future we can imagine this would be re-configured dynamically.

• The current structure of DAPLink requires to modify it to add support for new HICs and targets. It would be nice to be able to use DAPLink as a library or submodule, keeping HIC and target support out-of-tree.

• The current versioning scheme has a few drawbacks and will probably need to be revisited. Among the different limitations are:

  • no way differentiate feature and bug fix releases.
  • no way to release new or updated interface firmwares between DAPLink releases.

Citius, Altius, Fortius

This is the Olympic motto which is Latin for "faster, higher, stronger" (close to Daft Punk's "Harder, Better, Faster, Stronger", but I think things are already hard enough).

I am hoping this next release will lay the groundwork for faster development, a higher number of contributions and a stronger collaboration.

[simudvarac]

Thx for all the Work Mathias!
We are very excited to see the experimental support for lpc55 being continued.
The first tests of this are very promising.
Happy to hear also that gcc is going to be widely supported.
We are happy to help in future, be it with testing or with contributing code.
Keep up the great work!

[robschw]

Hello!
I have to join in thanks from Miroslav.
Thank you, thank you, thank you Mathias for your great work.
I have three questions:
(1) Is there a pre-release version of HIIC-HAL NXP LPC55S69 for IF / BL?

(2) How can SWO be integrated into the LPC 4322 or LPC55S69 (using UART)?

(3) Can you compare which Revision History of CMSIS-DAP the version DAPlink 254 is?

I have to thank you again for the contribution.
With regards
Robert

[mathias-arm]

• 1: You can find binaries for lpc55xx BL/IF on the compilers-test-status wiki page. To install on a MCU-Link, you can use the ROM loader and the MCU-Link software. This is all from the develop branch which you should be able to compile yourself.
• 2: lpc55xx supports SWO and there is a PR (lpc4322 cleanups for GCC #813) for lpc4322.
• 3: DAPLink 254 use CMSIS-DAP V2.0.0.

[robschw]

Thank you for the quick information.
I'm a little impatient and want to ask when there will be a release of 256.

Thank you very much
Robert

[mathias-arm]

I am not going to give you any date, but we are getting close to a beta (see #861). Most of the development is, I think, behind us, so a release will depend on how fast we can test and fix the issues we find.

[robschw]

Hallo!
I tested the "develop" version.
Please look at issue LPC55S69_IF and MCUXpresso #831
best regards
Robert

[0Grit]

Is project-generator still the best solution considering some of the new open cmsis-packs work?

Wish someone would share whatever big secret is being kept about the Mbed project.

[mathias-arm]

We are keeping an eye on Open-CMSIS-Pack to see if this is something we could leverage for DAPLink. I am interested in what you see as downsides in our use of project-generator and/or what upsides moving to Open-CMSIS-Pack would bring.

[0Grit]

My thinking is elegent Kiel studio support.