Debugging 504 DAPLink errors

[microbit-carlos]

Problem to investigate

Some environments are seeing DAPLink 504 time out errors more often than usual.

To debug this issue we've created a test Python script, that combined with a special DAPLink build, captures debug information while continously flashing a microbit.

Download the test programme

People having this issue will be directed to this GitHub issue to run this test programme and report back.

The test programme can be download it in this zip file: copyhex_v1.0.1.zip

Running the test programme

All the information required to run the test script is included in the README.md file inside the zip file.

In essence, there are two steps:

1. Update the micro:bit firmware with a special build included in the daplink folder
2. Connect the micro:bit to the PC and in a terminal run python3 test_cp_file.py

By default the script is configured to run 100 times, which will likely take around 1 hour to complete. This might seem like a lot, but in some environments we only capture one or two errors per 100 runs.

If you can't run the test for that long, or there are enough failures captured in less runs (for some users this problem is a lot more frequent), then the number of runs can be changed by modifying the TOTAL_RUNS = 100 line at the top of the test_cp_file.py script. Or alternatively, the programme can be stopped at any point by pressing Ctrl+C in the terminal.

Test results

The test results are stored in the serial_output directory. If you could zip and send us the serial_output folder we can then analyse the results.

[EricPobot]

I've just started the test with a V2.00 board I cannot program anymore because of repeated Err504 when downloading the hex to it from MakeCode.

The test is currently running, but 7 out of 17 runs have failed already. The common point I've noticed is that the mount and unmount delays are very different. When the test passes, they are both null. When it fails, unmounting takes between 18 and 24s and mounting takes between 3 and 6 seconds.

I'll execute the test anyway on a v2.20 board too ASAP.

Maybe this can help, there's a thing I've noticed when programming V1.5 boards. Even if the program hex file is correctly transferred and no anomaly occurs afterwards during the run, a FAIL.TXT file is present on the MICROBIT pseudo disk, with the "error: The transfer timed out." message in it. I could observe this behavior with every micro:bit v1 I've developed applications for since my the very first time.

[EDIT] I don't know if this is important, but when the Err 504 scenario happens, the same sequence of events can be observed :

• the program is uploaded to the micro:bit
• it starts running and behaves as expected
• the Err 504 messages appears after some delay (can't say how long exactly, but it's at least 10 seconds or more)
• at the same time, the pseudo-disk is mounted (my settings opens the file browser automatically when a new volume is mounted) with the FAIL.TXT file in it

Hope this helps.