Using DAPLink in a full project without USB

[GiulianoFranchetto]

Hi everyone,

We are currently evaluating how to build our mass-production programmer/tester nailbed board, and I was wondering if DAPLink could be used kind of as a library for an external project.

The idea is to flash the interface MCU embedded on our programming board with the following capabilities:

• USB connection to an host computer for communication with our production desktop program, but not to flash the target
• I2C communication with the target to start/get result for various tests
• SWD communication for flashing target(s) (if possible, there are 2 targets to flash on our target board, nRF5340 and nRF9160. Doing both in parallel would be awesome!)
• SDCard interface where the actual firmware to flash to the target resides

As you can see, this is different from what DAPLink offers by default, and I don't know if this project can be customizable enough to achieve what we need.

Had some of you already tried?

If not possible, could you point me some directions because to be quite honest, I don't really have a clear view of how to tackle this problem.

Regards
Giuliano

[mathias-arm]

It sounds like something that could be doable as a DAPLink board.

The Micro:bit Educational Foundation has done a lot of work and created a lot of hooks in DAPLink for kl27z_microbit_if that would help with your project. You should have a look in source/board/microbitv2: it shows how to extend the main loop, expose custom content through MSD, etc.

USB connection to an host computer for communication with our production desktop program, but not to flash the target

A board can implement DAP_ProcessVendorCommandEx() so you can create custom CMSIS-DAP commands, to trigger operations, query status, etc. DAPLink also implements CDC ACM for UART communication with the target, if you don't need to access UART from host computer, you can re-use the CDC channel.

I2C communication with the target to start/get result for various tests

The micro:bit V2 implements an I2C peripheral for the target. We are aware of similar use-case with I2C, SPI, etc.

SWD communication for flashing target(s) (if possible, there are 2 targets to flash on our target board, nRF5340 and nRF9160. Doing both in parallel would be awesome!)

We have fairly confident that SWD for 2 (or more) targets can be supported, but not in parallel. With a second core you might be possible to create a second DAPLink image but it would need a lot of work. If you need parallel programming a second DAPLink probe will be much easier/faster.

SDCard interface where the actual firmware to flash to the target resides

We don't have anything but most SDK have drivers and examples to read FAT filesystems.

Out of curiosity which MCU are you planning to use?

[GiulianoFranchetto]

Thank you for the intel, I'll check it right away.

Out of curiosity which MCU are you planning to use?

We don't have any MCU in mind for now, as I'm pretty sure it will be driven by our software needs.
I'm open to any MCU right now.
Is there a specific family that would be easier to use for DAPlink?

[mathias-arm]

It was mostly curiosity. Given the amount of functionality you want to put in, you probably want to use something with enough RAM and Flash, so towards the higher-end of what we support (see here).

[GiulianoFranchetto]

For our project, is it possible to "just" take the flashing part of DAPLink and remove all the rest of the functionality ?
If I over-simplify, I would only need functions like:

• connect to target
• reset
• program

[mathias-arm]

Most of the functionality you are talking about is concentrated in 3 files

• source/daplink/cmsis-dap/SW_DP.c: bit-banging SWD.
• source/daplink/interface/swd_host.c: SWD communication and reset.
• source/daplink/interface/target_flash.c: flashing.

There are obviously a lot of additional supporting files you are going to need:

• General DAPLink and CMSIS-Core hearders
• For the target side you need the description and flash-algos (source/target, source/family/nordic)
• If you are using one of the MCUs we support you should be able to reuse DAP_Config.h and gpio.c.

Overall I would say it should not be too hard, but it will not be trivial. I you do use one of the platforms we already support, I would encourage you to consider using DAPLink and extend it in a similar way micro:bit did. There could be a lot advantages to it than you would think.

[GiulianoFranchetto]

I'll check if any of the targets can fit our needs.
We are usually using nRFx chip in all of our product, so there is a great chance that this will be our final choice.
I'll start working on the subject today.

[flit]

If you get this working, it would be great if you could upstream support for automatic programming and SD card support!

[GiulianoFranchetto]

We are also evaluating using Zephyr for our "flashing/testing" board.
This is the OS we are mainly using in all our dev.
Unfortunately, they don't have official support for SWD yet.
If DAPlink (mbed if I'm not mistaken) is chosen, I'll try to create a not-too-ugly code that can be upstream.
However, I'm not used to mbed coding style, coding philosophy, tips and tricks etc...

[mathias-arm]

DAPLink does not use MbedOS, it might appear so because DAPLink has been using the MbedOS build tooling. It uses CMSIS-RTOS (we are moving from RTX4 to RTX5) for the interface and bare-metal for the bootloader. The rest comes from CMSIS packs or vendor SDKs.

[0Grit]

I'd like to see a port to zephyr as well. More generally a platform abstraction layer would be ideal.

[mathias-arm]

There has been some discussions about evolving DAPLink more into a "library", or making some of its features accessible as a such. We could contribute/assist in efforts to create nice some abstraction layers. If we wanted to do a full platform abstraction layer the most difficult would be USB.

[GiulianoFranchetto]

In my (very) narrow vision, I'd say that USB itself is not a core functionality of a "flashing a core using SWD" library.
This would be more of an external module, dedicated to fetch the firmware to program into the target.

The core library would be:

• The programming algorithm dedicated to the target with a well-defined state machine
• Formatting proper SWD messages
• Memory checking

Some modules will then be "plugged" to the core library, like for example:

• Fetching the firmware (and maybe decrypt it ?)
• Orchestration (flashing multiple targets with the same interface MCU)
• Profiling the programming of the target (for some log, like duration of each programming, detailed error code).

This will allow to use the core library within any "flashing" firmware, without automatically adding functionality that will not be useful, waste memory or worst not be supported by an interface MCU (like the lack of USB peripheral).

If I take the drag-n-drop functionality for example, this is only useful for devkit programming. For a production programming board, I don't want to pay a guy just to drop a file into a USB key all day long.

DAPlink itself would be a firmware built by linking the core library and adding all the needed modules + out-of-scope functionalities (like blinking led during programing or whatever).

An other advantage of the core library is that it's OS-unaware by design. The only hooks to be implemented by the OS would be memory management (malloc and so on), timing (sleep), gpio.

The "full" flashing firmware could then use whatever OS the dev. want. If we take Zephyr for example, the number of supported core is just huge, and pretty much all the low-level drivers are available and easy to use (SDcard, USB, even Bluetooth if for example one would want to get real-time update of the programming process wirelessly).

I realize that these changes will need a full rework of the DAPlink project, I'm just thinking/dreaming out loud here.

[raveslave]

@GiulianoFranchetto did you get this running?