DAPLink Performance

[simudvarac]

Not sure if I am violating any policies here or my previous question was deleted by accident, so I am going to repeat it, and if it disappears again so I will understand and not ask again. Thank you!

We are working on a DAPLink powered SWDAP clone (LPC11U35) and are experiencing some performance issues.

My investigation yesterday led me to test the performance on a Nordic DK52 Kit using a SAM3U2C processor running JLink OB.
I flashed the same file (600KB) to the onboard NRF52833 using both the JLink OB with JFlash Lite and a DAPLink using OpenOCD.
Both times I mass erased the chip and measured the times.
JLink: 4,2-4,5 seconds
DAPLink: 12-14 seconds

Is that a result to be expected?

[elfmimi]

I'd say those results are some what expected ones. JLink utilize efficient proprietary protocol.
DAPLink is yet to achieve that level of efficiency.
By the way, you should be more specific about the version you used.
From your previous topic, I'm guessing that you must used lpc11u35_tiny_if_crc.bin or lpc11u35_if_crc.bin .
Out of these two lpc11u35_if supports bulk mode transfer. You'll need the latest openocd-0.11.0 to take advantage of this.
So if you haven't tried it yet, I suggest taking another measurement with bulk mode transfer in use. I'm also curious about the result.

[simudvarac]

For my tests on the Nordic Board I used the 0253_SAM3U2C_MKIT_DK_DONGLE_NRF5X_0X5000.BIN
I can try the bulk mode on our SWDAP clone to see if the performance increases.
Yesterday we tried also the MCU-LINK with the DAP Interface it comes with and there we got much better results, 6 seconds only.
Trying to get the latest LPC55 Daplink onto the MCU-Link to check its performance.
I will perform the bulk test and keep you updated.
Thank you for your support!!!

[simudvarac]

We did the test with an FW we built using your hint and I must say WOW.
It doubles the speed on the LPC11U35 from over 15 seconds to some 7.5-8 seconds.
Is this bulk feature also already supported on the LCP55 like MCU-Link?

[elfmimi]

I don't know about MCU-Link , but maybe it is fast thanks to its high-speed USB connection.

Is this bulk feature also already supported on the LCP55 like MCU-Link?

This is ambiguous. LPC55 is only supported as a target in DAPLink. if I understand it correctly.
Bulk made transfer is a feature which resides in a connection between a debug adapter and a host PC.

[elfmimi]

Sorry, I was looking at a month old codebase.
You mean this? #803 Yes, bulk mode should be there .
I'll try to test this myself.

[elfmimi]

I got my MCU-Link and tested it with DAPLink firmware from this repo - experimental_compilers branch.
It works with openocd-0.11.0 .
It does not work with pyOCD somehow. Yet to investigate about this.
My target is nRF52840 . I'd like to compare preformance of lpc11u35_if and lpc55s69_if in few days.

[simudvarac]

Now we did some more testing and the openocd speed for the 600k is constantly double the speed of the old fw without the bulk mode on the lpc11.
However the drag&drop part got much slower, up to 19 seconds from 13 seconds before.
Any idea why is that?
Will try the MCU-Link as soon as we find out how to program it. Using the Nxp updating scripts failed and also connecting the jlink to the swd on the back worked only for the bootloader, maybe our build is not right. If you get there before, please advise what you did.

[simudvarac]

Hmm, we did not manage to get the MCU running with the build from the branch. We tried the boot loader method and also directly writing the fw using jlink, none of them worked.
You say, after flashing bootloader you were able to boot into crpdisabled and just copy the firmware onto mass storage and this left you with a working programmer?
Can you share the binaries and shortly describe the process?
Do you also have drag&drop now?

[elfmimi]

files've been put here -> https://github.com/elfmimi/DAPLink/releases/tag/v254%2B

I used pyocd and another CMSIS-DAPv1 adapter to program the bootloader.
python -m pyocd flash -t lpc55s69 lpc55s69_bl.hex
reconnect it. and then cp _if.hex to the bootloader drive.

edit
above applies only for the very first time.
you'll need to populate a jumper at J4 or J5 to get bootloader activated.

Do you also have drag&drop now?

No. I'm also looking around for answer for that.

[elfmimi]

I've got drag&drop feature working on MCU-Link for nRF52840 target.

• combined lpc55s69_if with records/board/mtb_laird_bl654.yaml

I had to take care of two occurrences of asserts.

• osThreadGetId() for usbd_msc_init does not match with the rest of vfs_manager.c's functions which are calling sync_assert_usb_thread() .
• util_assert(SystemCoreClock < 100000000) in hic_init.c . this can be simply ignored.

I'm not satisfied with its performance of about 20KB/sec . There must be something we are overlooking to improve this.

[elfmimi]

I was assuming drag&drop flashing is using the last clock rate setting used by openocd or pyocd. but it turned out incorrect. drag&drop flashing is using the default setting set up by DAP_Setup() which is 4MHz clock rate in case of lpc55xx hic .
I modified it to use fast_clock mode as default setting , which forced me to set DELAY_FAST_CYCLES == 2 , and then
flashing performance jumped up to about 50KB/sec. Great! may be this is kind of fastest reachable speed without utilizing peripheral specific tricky codes.

[rafatuski]

Dear elfmimi,

is there any chance that you post or provide some testing binarys with working drag&drop ? :)

Thanks & Best regards

[mathias-arm]

Some of the performance difference will probably come down to the hardware:

• lpc11u35 is a Cortex-M0 running at 48 Mhz.
• sam3u2c is a Cortex-M3 running at 96 Mhz supporting USB High-Speed.

[simudvarac]

We are of course always testing on the same HW.
sam3u2c is the chip on the Nordic DK where we tested both, JLink OB FW as well as the official Daplink release.

[mathias-arm]

Sorry, the thread is bouncing back between lpc11u35 and sam3u2c, I got confused by the different comparisons (I thought you connected your SWDAP clone to the Nordic DK52 debug port).

For flashing, CMSIS-DAPv1 is very likely be slower than drag&drop because it incurs a lot more of back and forth. The bulk mode should reduce the performance difference (if not remove it completely).

There is a 0254 release that includes bulk endpoints.

I am not too familiar with openocd. According to their respective release notes, it seems pyocd added support for CMSIS-DAP v2 bulk mode two years prior to openocd. You might want to try out pyocd to see if it improves things.

[simudvarac]

It works with the newest openocd and the bulk fw on lpc11 just fine.
We get a performance boost of 50%. 6.5 sec compared to 13-15 seconds before the bulk.
What we do not understand, and maybe its a bug, is that drag and drop now is slower then before. Drag and drop used to be the same as openocd, 13-15 sec, now it is 19 seconds.
So the bulk endpoint fw improved the openocd only makind d&d worse.
Can you confirm that too? Does it happen for other MCUs?