I am beginning a project where I will be creating a custom board. I am undecided on what MCU I will use, though it looks like it is between the Renesas RZ/A1H from the GR-PEACH or the STM32F767ZIT6 from the NUCLEO-F767ZI. What I don’t fully understand is how integrating DAPLink on a custom board for these controllers works even after reading up on DAPLink. From what I can tell, there are several MCUs that can function as a DAPLink interface, such as the LPC11U35 or STM32F103CBT6, but what I don’t understand is how the firmware for an interface chip works. Is the firmware on the interface chips generic and they all serve as programmers for any MCU? Or in the case of the GR-PEACH I found a firmware at DAPLink for the GR-PEACH in particular for an LPC11U35, meaning I’m limited to using only the LPC11U35 as a programmer? And that same webpage also returns no results when searching for Nucleo boards, so if DAPLink firmware is target MCU specific, where would I find that firmware? If anyone can clear that up, that would be great, thanks!
The Nucleo boards don’t use DAPlink as far as I know, they use ST-LINKV2 for the most part. The same thing that is in a standalone programmer, but just soldered on the Nucleo board.
Documentation for DAPlink is terrible. Then I found THIS LINK.
Apparently, The interface is common, and if your target supports either SWD or JTAG, the interface chip and firmware is irrelevant. Especially since you can buy DAPlink programmers and connect them via standard 9-Pin Cortex M Adapter to any Cortex M board.
Right, that’s sort of what I thought. The main issue right now, and I guess I should have included it in the original post, is that in developing this custom board, we also want to keep the easy drag n drop functionality of the nucleo (and from what I understand the GR-PEACH as well, though we don’t have one yet) . This is mainly to keep things easy for customers when they need to update firmware, because that needs to be kept as easy as possible. I have not used one myself yet, but coworkers in my office have used a standalone ST-LINK to program other devices, and they needed other software (PlatformIO I think) to program the device they were targeting. That’s not really possible for us to do because it’s not easy for customers. So in that case, the onboard DAPLink/ST-LINK setups that I’ve encountered would have to have target specific firmware, correct? Mainly to enable that drag n drop programming interface
Firstly, you need platformio just for compilation. You can just give .bin/.elf file to the users. Then your users need something simple, like ST-LINK utility, which is pretty lightweight (26 MB) and can flash boards in few clicks (Open .bin/.elf, connect to target, flash, OK).
Second, It’s a bit more work, but you can write your own st-link firmware updater, using something like OpenOCD, which can one-click flash your boards.
And third, I don’t think that it would still need to be target-specific. DAP link is essentially ST-Link + UART for debugging purposes + Memory.
The DAPlink acts like a USB memory, when you drag and drop a .bin file, it stores it in memory and then flashes it on the MCU, which is equivalent to using ST-LINK utility, choosing the same .bin file, and flashing it. It’s just more convenient.
For the STM32 MCU, the newer STLink V3mini can be used. This is very tiny and available as simple board that can be soldered on the main board. There you have also the USB MSD for drag’n drop programming, but it supports only STM32 MCU.
The source code for DAPLink is on github, but afaik you still need the Keil compiler to build your binary. There is a documentation about how to add new targets.
Ah, okay that clears things up. Looks like we may not need that functionality, since we are looking at incorporating a bootloader instead now, but I wasn’t even aware of the ST-LINK V3, so that is good to know! Thanks for everything!
