Feature: Runtime Configurable Target Support

[0Grit]

I've been holding this one back for a while, can't beat around it anymore.

What is the feasibility of enabling daplink to change its 'target' target at runtime?

What would it take to make this happen?
And if I'm missing something and this is already sort of possible (maybe by cutting out drag/drop flashing) I'd love to get ahold of documentation.

@flit @cederom @BlackstoneEngineering

[0Grit]

#389 (comment)

^That answers some of my questions. Is there somewhere in documentation that explicitly states this info?

[0Grit]

Also, I'll be RTFMing this answer myself shortly, but how is greentea using daplink?
Does it use MSD interface or SWD for flashing and why?

[0Grit]

@cederom Thanks for this https://github.com/cederom/DAPLink/blob/cederom_doc/doc/DAPLinkHandbook.md

[brianesquilona]

@loverdeg-ep, there are ways to change a target-id during runtime, currently you can change your source/board/board.c file const char *board_id, assign it as you like, but this will change once #559 is merged and I am taking notes on what to add in the documentation #573. For drag-n-drop, as long as your flash algo supports it, then it should be fine.

[BlackstoneEngineering]

@loverdeg-ep
Currently DAPLink is compiled with the flash algo's for just one target, to enable your situation of a single interface binary being able to program multiple target chips you would need to enable flash algo's for multiple targets. This is not a mainline feature that is planned at the moment that I am aware of.

@flit and @brianesquilona to comment further on this.

[flit]

We've discussed multiple times over the years about building support for multiple targets into a single DAPLink binary. We could do single per-vendor builds, as automatically identifying the target at runtime given a known vendor is relatively straightforward for most families. But determining vendor is an open problem. We do not want to implement something where the user has to select the target.

The code needed major reworking to support this. The first step of supporting multiple families in one build has been implemented in #559. Next, we would need to support multiple targets and flash algos, plus the logic to identify the target.

[0Grit]

Talking without using brain; Can the flash algorithms be patched post build via MSD command. They are position independent correct? Might be dirty but could be a start.

We will be developing custom targets more often than the average user, but we are having a heck of a time getting fully automated greentea tests to work for our NRF52840 based custom target.

• GCC is our toolchain, so unless I'm mistaken we aren't going to be doing our own build of daplink
• daplink firmware for NRF52840-DK doesn't support debug out connector
• j-link firmware for NRF52840-DK doesn't seem to have automation mode to reset device after MSD firmware flash
• We overnighted some ibdaps but they are LPC11u35 based and there is no daplink release for it that targets NRF52840
• We haven't searched super extensively but we can't find any suppliers of generic probes using any of the other HIC's that have release builds for NRF52840.

It has been a not fun experience trying to do a custom_target "the right way".
Some extra post-build configurable options in daplink would be really nice.

Will make new issue for the above rant upon request.

[0Grit]

@dlfryar please see comment above

[dlfryar-zz]

@loverdeg-ep there are a few options to work through this. I'll have to verify with boards in hand and get back to you.

• PR#559 is going to allow custom algorithms per interface chip with some assistance from an algo script.
• You could use one of the NXP boards e.g. FRDM-K82F that has recent DAPLINK boot loader (note: not older read only P&E firmware), cut the trace from the MCU to the interface chip, build DAPLINK for the NRF (arm compiler needed) and run it on the NXP board connected to your NRF custom board via SWD/tag connect
• Future items that will give additional options are new standalone Daplink modules and possibly Greentea JLink support

[flit]

@loverdeg-ep We clearly understand the issues you face for custom targets and are working to address them.

Specifically about the flash algos, in order to support patching or replacement of the algo via MSD, the algo would have to be isolated into its own flash sector. So yes, it's definitely possible. But imo, it'd be better to just use pyOCD (or other host tool) to flash the target.

Btw, we are getting an IBDAP so we can, among other things, create a DAPLink port. Should just be a custom IO config for the LPC11U35 HIC.

[dlfryar-zz]

Here's the post that explains how to use one of the NXP FRDM boards to debug another target.

[0Grit]

@flit If you can release a daplink binary that enables the Debug Out connector for the NRF52840-DK that would be a pretty quick workaround as well.

If that is a possibility let me know and I'll make an issue that documents the required IO_Config_Override.h

[0Grit]

@dlfryar Per your recommendation to use FRDM boards. We'll be using gcc till an open source llvm/clang solution becomes viable.

Under current circumstances we'll need one of the following to unblock us from having fully automated testing of our board.

• @flit If you can release a daplink binary that enables the Debug Out connector for the NRF52840-DK that would be a pretty quick workaround as well.

• To be pointed in the direction of a debugger/dev board that supports one of the HIC's with a binary release that will support MSD for NRF52840 (that or same flash algo I guess).

• Find a way to get greentea/htrun to flash tests via Jlink-ob of nrf528XX-DK

• Find a way to get greentea/htrun to flash tests via jlink-base