armmbed / daplink Goto Github PK

License: Apache License 2.0

C 96.72% Assembly 1.96% Python 1.27% Batchfile 0.04% Shell 0.03%

embedded cortex-m arm mcu debug cmsis-dap microcontroller firmware mbed

daplink's Introduction

Arm Mbed DAPLink is an open-source software project that enables programming and debugging application software running on Arm Cortex CPUs. Commonly referred to as interface firmware, DAPLink runs on a secondary MCU that is attached to the SWD or JTAG port of the application MCU. This configuration is found on nearly all development boards. Enumerating as a USB composite device, it creates a bridge between your development computer and the CPU debug access port. DAPLink enables developers with:

MSC - drag-n-drop programming flash memory
CDC - virtual com port for log, trace and terminal emulation
CMSIS-DAPv2 WinUSB (driver-less vendor-specific bulk) - CMSIS compliant debug channel
CMSIS-DAPv1 HID - CMSIS compliant debug channel
WebUSB CMSIS-DAP HID - CMSIS compliant debug channel

More features are planned and will show up gradually over time. The project is constantly under heavy development by Arm, its partners, numerous hardware vendors and the open-source community around the world. DAPLink has superseded the mbed CMSIS-DAP interface firmware project. You are free to use and contribute. Enjoy!

For more detailed usability information see the users guide.

Compatibility

There are many ARM microcontroller-based Hardware Interface Circuits (HICs) that DAPLink interface firmware runs on. These can be found as standalone boards (debugger) or as part of a development kit. Some branded circuits that are known to be IO compatible are:

Maxim Integrated MAX32625PICO based on MAX32625
Nuvoton Nu-Link2-Me based on M48SSIDAE
NXP LPC-Link2 based on LPC11U35 or LPC4322
NXP MCU-LINK on LPC55xx
NXP OpenSDA based on K20, K22, KL26Z and KL27Z
Segger J-Link OB based on Atmel SAM3U
STMicroelectronics ST-LINK/V2 (on NUCLEO boards) based on STM32F103CB

You can find more information on the microcontrollers supported here.

Releases

There are many board builds (board = HIC + target combination) created from this repository. Quarterly releases will contain new features and bugfixes. Standalone bugfixes are released once reported, verified and fixed. Both quarterly and bugfix releases will result in the build number being incremented. Many development kits and products ship with DAPLink interface firmware or are capable of running DAPLink firmware. The current release builds and instructions for updating DAPLink interface firmware is hosted on the DAPLink release site. Release notes and previous release builds can be found under GitHub releases.

Contribute

We welcome contributions to DAPLink in any area. Look for an interesting feature or defect under issues. Start a new thread in the discussions or in Slack to engage with the developers and maintainers.

Please see the contribution guidelines for detailed requirements for contributions.

To report bugs, please create an issue in the GitHub project.

Develop

Information for setting up a development environment, running the tests or creating a release build can be found in the developers guide.

License

DAPLink is licensed with the permissive Apache 2.0 license. See the LICENSE file for the full text of the license.

daplink's People

Contributors

Stargazers

Watchers

Forkers

c1728p9 sukidog redbear flyleaf91 gamnes bridadan alexk2k12 embeddedartists elektor-labs stevew817 cerevo ming-hai theotherjimmy wjzhang bygreencn erichstyger mesheven augustofg flit gurumin jonneva tomoyamanaka sklli dolma3000 multitechsystems andcor02 lanselambor kgills mazgch happierkang dobypig0303 hackerdd jamesadevine zhangshengping owenbrotherwood tiancheng-luo geoffreymbrown d-kato yottastone seeedstuff timmmm galak devanlai blackstoneengineering golf2109 ianhom feijie825 luyang14 seppotakalo ubirch lvjh wonderfulsuccess anlaim fbsder kaizen8501 xllj multisensor vincentwilliam liuxinbai hoverxx pengshulin mimaki djm595079527 gauthi007 studavekar awais174 invs007 mtmtech ytsuboi fahimalavi clarephang marrtn wanming2008 i-syst mgyuli dontech kevinxusz maggiemei schautsang andreaslarssonublox gorazdko matthewelse u-blox tung7970 iotmember cederom lyplcr simtind dinwind neoyong dmsg jemkzheng okwh carlosperate bingyuz zhj2232006 blackramelectronics neomissing zhengyangliu acabarbaye

daplink's Issues

Failed to flash FRDM-KW24D

I was in assumption that FRDM-KW24D is supported.

However, the release package contains 0243_k20dx_frdmkw24f_0x8000.bin binary. I assumed that is it only typo, and tried to flash and got following error on Mac:

It did not update the firmware. Just rebooted the bootloader.

Then I tried again in Linux:
I did not see any error messages, but following was visible in dmesg

[10529801.975734] usb 3-5.1: new full-speed USB device number 13 using xhci_hcd
[10529801.994286] usb 3-5.1: New USB device found, idVendor=0d28, idProduct=0000
[10529801.994293] usb 3-5.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[10529801.994296] usb 3-5.1: Product: MBED BOOTLOADER
[10529801.994299] usb 3-5.1: Manufacturer: MBED
[10529801.994301] usb 3-5.1: SerialNumber: ffff1000C82F6E5FD82F91A0
[10529801.995390] usb-storage 3-5.1:1.0: USB Mass Storage device detected
[10529801.995511] scsi15 : usb-storage 3-5.1:1.0
[10529802.991977] scsi 15:0:0:0: Direct-Access     MBED     BOOTLOADER            PQ: 0 ANSI: 2
[10529802.992326] sd 15:0:0:0: Attached scsi generic sg4 type 0
[10529802.992627] sd 15:0:0:0: [sdd] 240 512-byte logical blocks: (122 kB/120 KiB)
[10529802.992844] sd 15:0:0:0: [sdd] Write Protect is off
[10529802.992848] sd 15:0:0:0: [sdd] Mode Sense: 03 00 00 00
[10529802.993076] sd 15:0:0:0: [sdd] No Caching mode page found
[10529802.993080] sd 15:0:0:0: [sdd] Assuming drive cache: write through
[10529802.994713] sd 15:0:0:0: [sdd] No Caching mode page found
[10529802.994717] sd 15:0:0:0: [sdd] Assuming drive cache: write through
[10529803.002725]  sdd:
[10529803.003801] sd 15:0:0:0: [sdd] No Caching mode page found
[10529803.003805] sd 15:0:0:0: [sdd] Assuming drive cache: write through
[10529803.003809] sd 15:0:0:0: [sdd] Attached SCSI removable disk
[10529829.404406] usb 3-5.1: USB disconnect, device number 13
[10529829.438580] FAT-fs (sdd): unable to read boot sector to mark fs as dirty

Then board just lid all leds on board. It did not restart the bootloader.
Board did not reappear anymore, even after unconnecting&reconnecting. Now only bootloader mode works(connect with RESET pressed).

micro:bit 0243 has html that points to https://www.microbit.co.uk/

the html redirect is to https://www.microbit.co.uk/ I wonder if this is correct?

<!doctype html>
<!-- mbed Platform Website and Authentication Shortcut -->
<html>
<head>
<meta charset="utf-8">
<title>mbed Website Shortcut</title>
</head>
<body>
<script>
window.location.replace("https://www.microbit.co.uk/device?mbedcode=99000243");
</script>
</body>
</html>

# DAPLink Firmware - see https://mbed.com/daplink
Unique ID: 9900000036424e4500413014000000140000000097969901
HIC ID: 97969901
Auto Reset: 1
Automation allowed: 0
Overflow detection: 0
Daplink Mode: Interface
Interface Version: 0243
Git SHA: b403a07e3696cee1e116d44cbdd64446e056ce38
Local Mods: 0
USB Interfaces: MSD, CDC, HID
Interface CRC: 0x14256f44
Remount count: 1

Please add documentation regarding automation features

Automation feature (flashing bootloader in automated way) and other features we do not know about.

Request for K64F DAPLINK reset without reset to the MCU.

Some of the cases where the K64F board has totally frocen from the system point of view, it would be nice to inspect is it DAPLINK that has frozen or the application running on the MCU.

NRF51_DK firmware in release package invalid

For the NRF51 DK board that I have, the firmware from the release package does not work (Daplink drive does not enumerate).
0241_sam3u2c_nrf51dk_0x5000.bin

However, if the following other binary works (also from 0241 release, but not in the separate binary release package)
sam3u2c_nrf51dk_if_crc_legacy_0x8000.bin

Provide information on the "progen" command

I'm reading through the Developers-guide and one of the steps asks me to run

$ progen generate -t uvision

This fails for me, presumably because I do not have "progen" installed. While researching, I came across this python library, which seems really similar. However, after installing it, the command still fails because the "uvision" generator does not exist.

Is this the correct library? Could you provide some more details on how exactly to install/use the progen command?

Doesn't display "DAPLINK" message when upload DAPLink firmware using ISP boot mode of LPC11U35

Hi, I have a problem using DAPLink on LPC11U35.

I try to update to DAPLink from CMSIS-DAP using WIZwiki-W7500. WIZwiki-W7500 use LPC11U35 for interface. This is schematic of WIZwiki-W7500.

WIZwiki-W7500 V1.1 Schematic (PDF)

It is success when I upload firmware of LPC11U35 using JTAG(ULINK2). It can display "DAPLINK" well in my PC as this picture.

But If I upload binary using LPC11U35 ISP Boot( CRP DISABLD ), It doesn't display "DAPLINK" after done. It only display "CPR DISABLd" in my PC.

Is there anybody who help me?

My DAPLink interface does not reset target (nRF51822) after download program.

Hi.
I have a problem with DAPLink interface.
DAPLink connect to nRF51822 over SWD (SWDCLK, SWDIO) and TX, RX.
If I use drag-drop method with MSD to program firmware to target, target will be reset after done (Automation-allowed=1, Auto Reset=1).
But after I download program to target (DAP-HID), target will not be reset!
That is my problem. Please help me! Thanks

What is the assumed environment for the commands shown in DEVELOPERS-GUIDE.md

For the commands shown in the DEVELOPERS-GUIDE.md , what is the assumed environment.
I'm using Windows 7 Pro x64, and I am using the Git Shell command window (which is Microsoft's
PowerShell). This was installed from https://desktop.github.com/ which installed both the
GUI interface for Github, and the above mentioned Git Shell command window.

Unlike the examples in the guide, instead of a prompt of '$' , I get prompts like this:
D:\GitHub_Clone\DAPLink [master ≡ +2 ~1 -0 !]>

The issue arises at Step 2, where the activate and deactivate commands are quoted:
"venv/Scripts/deactivate"

When I enter them as above, the text is echoed back without the quotes, but no command
is actually run. If I leave the quotes off, the commands run correctly.

Is this an error in DEVELOPERS-GUIDE.md or should I be using some other command
window (in which case maybe that should be documented in the guide)?

Thanks.

Cannot build source without a git repo

DAPLink cannot be built without having a valid git repo.

[Build 0240] Enumeration fails on win7/8 without mbed serial driver

The enumeration change breaks the enumeration without errors when the mbed serial driver is not installed. Need to investigate stalling the CDC endpoint after MSC and HID such this only presents itself when the driver is installed

0a83401

Add link to HDK from Readme

Need to add link to the HDK from the readme file to complete the circular linkage from the HDK page.

Something like

Hardware Reference Implementation

DAPLink Reference Designs can be found in the mbed HDK DAPLink Reference Design projects.

How to make DAPLink firmware support STM32F412ZGT6 and STM32L443 MCUs?

We’re developing DAPLink firmware with the board based on NXP LPC11U35 and we also follow the design of https://developer.mbed.org/platforms/SWDAP-LPC11U35/ as reference to develop the DAPLink board. However, according to the spec of SWDAP-LPC11U35, it only supports main targets like NXP K64F/NXP LPC1768/Nordic nRF51822.

We were wondering how we can make our DAPLink board support STM32F412 and STM32L443 targets? What is required from our side to develop the DAPLink firmware?

Support GCC

It would be nice if you didn't have to spend thousands on a Keil license to compile this!

Please release this software in GitHub

Please start releasing software :)

You can start by source versioning using this way: http://semver.org/ - yotta module way.
Please take under consideration implications from major, minor and patch versions.
Please tag this repository accordingly. Where is version 0240 in this 740+ commits now?

post_computer_crc starting address.

This code is from tools/post_compute_crc.py.

    if start == 0x8000 or start == 0x88000:
        pad_addr = start - 0x3000
        # Create hex file
    elif start == 0 or start == 0x80000:
        pass
    else:
        assert 0, "Unsupported start address 0x%x" % start

Can someone explain what's going on here. It seems to be creating hex files for the interface firmware and not for the bootloader. The issue that I'm having is that when the interface firmware starting address is not at 0x8000 or 0x88000 I get an error.

The HIC I'm working with has a flash sector size of 0x2000. I don't have enough room for the bootloader code and have a page for the "CONFIG_ADMIN" page.

usb power off/on produces a non attachable K64F

Raspberry Pi 3, LDM device manager and 0241 DAPLINK.

After a around 30 power cycles, we start too see this kind of issues is dmesg:

[ 1368.413390] usb 1-1.4.1: USB disconnect, device number 78
[ 1368.448472] FAT-fs (sda): unable to read boot sector to mark fs as dirty
[ 1374.788626] usb 1-1.4.1: new full-speed USB device number 80 using dwc_otg
[ 1374.868620] usb 1-1.4.1: device descriptor read/64, error -71
[ 1375.058653] usb 1-1.4.1: device descriptor read/64, error -71
[ 1375.248675] usb 1-1.4.1: new full-speed USB device number 81 using dwc_otg
[ 1375.328676] usb 1-1.4.1: device descriptor read/64, error -71
[ 1375.518685] usb 1-1.4.1: device descriptor read/64, error -71
[ 1375.708689] usb 1-1.4.1: new full-speed USB device number 82 using dwc_otg
[ 1376.128706] usb 1-1.4.1: device not accepting address 82, error -71
[ 1376.208708] usb 1-1.4.1: new full-speed USB device number 83 using dwc_otg
[ 1376.628801] usb 1-1.4.1: device not accepting address 83, error -71
[ 1376.629010] usb 1-1.4-port1: unable to enumerate USB device

That is after the power is turned on for the device, is DAPLINK resetting itself or what might be the reason for this kind of behaviour?

After the unable to enumerate USB device the system will not recognize the device unless the system is rebooted.

Is there any way to debug this situation i.e. wireshark from the USB interface? Is there anybody who could interpret the capture?

Releases on github

Would i be possible for a version of the current builds/releases to be included on the Github repo?, perhaps as a sub folder or as an external hosted link?

I have the issue that i do not have a full version of the keil MDK so cannot build the required interface firmware but it would be useful to be able to access them all up to date and in one place

thanks,

Joe

nina_b1.c line endings

Is it just me or does this file have ^M line endings? Git is acting funny and is saying that I have changes that I can't seem to get rid of.

Symbol missing

Hi All,

Just trying to get my dev environment set up to contribute to the firmware and i've run into an issue i can't solve without commenting assembler lines out 😉

..\..\..\source\hic_hal\freescale\kl26z\armcc\startup_MKL26Z4.s(235): error: A1185E: Symbol missing

Which appears to be this line here.

This should be defined by the uvision IDE, if I am correct... I've verified it is set!

Any ideas?

build_filesystem() called multiple times.

Hi,

build_filesystem is called from multiple locations, most notably on a VFS_MNGR_STATE_CONNECTED state.

build_filesystem is also called when the state is set to VFS_MNGR_STATE_CONNECTED, this causes the filesystem to be "built" multiple times during initialisation.

Give host a chance for a graceful MSD unmount after drag-and-drop flashing

Once drag-and-drop flashing finishes the state of MSD endpoint seems to be toggled, which causes various shake-ups in the host side. In desktop environment it typically triggers notifications that the device has not been ejected properly before removing.

With Linux kernels we sometimes observe that due to racing there may be several device nodes for the same MSD. This confuses tools, because one of these device nodes is a stall one and will disappear very soon. With multiple targets connected to our relatively weak raspberry pi boards the racing may really become an issue.

I think, if we could synchronize the host state before letting daplink trigger its state changes, it would help us to help more reliable system. What is your opinion?

0241 Programming Causes Assert

This image for Seeed Arch Link causes an assert when programmed. The assert is a hard fault.

Assert
File: ..\..\..\source\daplink\interface\main.c
Line: 167
Source: Application

Sending file by email

fea-request: flash sha1 to text file

I would like to see afterward what binary was flashed to the device. Build sha1 could be good unique value for this. This feature would be very useful for CI/automation.

e.g. Use case:

user#1 flash binary to the device
-> daplink write binary sha1 to some text file (e.g. DETAILS.TXT)
user#1 unplug device and give device to user#2
user#2 plug device
user#2 want to verify what binary was flashed
-> read text file and check sha1

Add command to erase flash

The ability to trigger a flash erase by dropping a file on the filesystem would be useful for some test workflows, so this feature should be added.

Wrong file name in docs/PORT_BOARD.md

https://github.com/mbedmicro/DAPLink/blob/master/docs/PORT_BOARD.md#adding-board-to-automated-tests

should be test/info.py, not test/into.py

USB HID

Hi all,

I'm working on some HID interface for the firmware, however there is already a default HID interface overriding the weak symbols defined elsewhere:

https://github.com/mbedmicro/DAPLink/blob/8b2e1efe883940e3f0432fcbf41640a691881f65/source/daplink/cmsis-dap/usbd_user_hid.c

Is there a way to override this implementation without deleting/commenting the code?

LPC11U35 HIF RST IO differences

#50

Need to look at SWDAP / DIPDAP, LPCXpresso, ublox C027, SSCI platforms and EA platforms. Probably warrants a spreadsheet to look for commonality and conflicts.

ATSAM3U UART buffers not properly cleared on CDC break or baud change

The ATSAM3U isn't clearing its buffers at the appropriate time. This needs to be fix and a test needs to be added to prevent future regressions.

Serial issue

This issue is revealed in the following PR: ARMmbed/mbed-os#382

The test case is the "echo" test that was removed. The behavior is DAPLink stops sending/receiving serial data correctly. After attempting to send and receive more serial data, eventually DAPLink returned to a good state. DAPLink also properly reset when the whole platform was power cycled.

Please contact me for me details on how to reproduce.

Need clarification on ASSERT.TXT file appearing on K64F rev 0241

Is this something major that we should be concerned about or is it something trivial that does not affect behaviour of the board.

No documentation on this issue.

The contents of the file:

cat /media/pi/DAPLINK1/ASSERT.TXT
Assert
File: ..\..\..\source\usb\msc\usbd_msc.c
Line: 237
Source: Application

Source application, does that tell that the application has hard faulted or something?

Building the binary for NXP TWR-LS1021A board

According to the "mbed.htm", the firmware version is 0203. Using this version, I have faced some issues regarding UART (UART-USB converter). I have also noticed the latest release (0242) has some fixes related to UART (#97). So I want to use the latest version 0242 for TWR-LS1021A board which is based on MK20DX128VFM5. I have followed the guidelines mentioned by DEVELOPERS-GUIDE.md. The problem is that I could not find this board specific code in the "source/board" directory. As this is based on the K20DX target, I have tried with "k20dx_bl.bin" but the board did not boot up.

Has anyone tried the DAPLink source for TWR-LS1021A board?
Do I need to port this source for the TWR-LS1021A board?

DAPLink doesn't work with IAR EWARM 7.7?

Hi,

I flashed my FRDM-K64F board's K20 with '0242_k20dx_frdmk64f_0x5000.bin' image download from latest releasee. And installed mbedWinSerial_16466.exe driver. I can see 'mbed composite usb device' 'mbed Serial Port' and 'DAPLin' device in device manager. But when I select CMSIS-DAP as debugger in IAR, it shows error when launching debug session

Source of flash_blob

I am trying to get custom STM32F401/F091 platforms supported by DAPLink on SWDAP/dipdap.

I assume I could start from lpc11u35_arm_watch_stm32f411_if and modify it to our needs. Would the flash_blob from https://github.com/mbedmicro/DAPLink/blob/master/source/target/st/stm32f411/flash_blob.c work also for F401/F091? If not, how could one get adequate blobs for ST? They do not seem to come from https://github.com/mbedmicro/FlashAlgo.

@MarceloSalazar

new target platform - how?

I'm trying to get a new platform up and running - a MKL17Z256VFT4 target processor and the standard MK20 interface processor.

I was able to build the bootloader for the interface processor and it seems to work fine. I'm currently trying to figure out how to get the target-specific files for the interface firmware: target.c and flash_blob.c. It seems that both of these files are somehow derived from the .axf file that I get when I build a flash algorithm project in Keil. I've been using the project at C:\Keil_v5\ARM\Flash\MKXXX\MKXX.uvproj and choosing the MKP256_48MHZ_KL43 target because I know the KL17 is highly compatible with the KL43. (I was able to get one of my devices working by swapping the interface processor from a kl43 dev board.)

My big question is how do I transform the .axf I get from building the flash algorithm project into the source files I need for my interface firmware? I know there's a script in the CMSIS-DAP repo that did this, but it doesn't seem to work out of the box with the .axf I generated.

Also, should I be using a different flash algorithm project to generate the .axf? Does choosing the MKP256_48MHZ_KL43 target make sense, or should I be using the more generic MKP256 (or something else completely?) instead?

I realize that this isn't really an "issue" (maybe the lack of documentation is, but we're all engineers here), but any help would be appreciated. I've got a pretty tight timetable to get this working.

Settings, and where to declare them

I see the latest commit to master pulls out the drive name, html file name and redirect link to a target-specific file in overrides. I assume the idea here is to separate target MCU from target board? If so, then the board ID and version ID should also move from app_config into the override file.

If USB reset occurs in the middle of SCSI command mass storage stops working

The USB stack does not propagate a reset to the endpoints. Because of this if a USB bus reset occurs in the middle of a SCSI transaction the device will stop responding to mass storage commands. This persists until the board is reset.

"problem copying" on windows 8 and some Windows 10

the DAPLink VFS will get the ERROR_ERROR_DURING_TRANSFER or ERROR_TRANSFER_TIMEOUT error when "problem copying" message on Windows 8 and some Windows 10

Potential null-pointer dereference when receiving serial data before USB is connected

While doing development on an STM32F103 HIC based on #133, I noticed that if the target MCU sends serial data very early on, the DAPLink firmware could encounter a bus fault.

I'm currently testing with this target program:

#include "mbed.h"

Serial pc(USBTX, USBRX); // tx, rx
int main() {
    pc.printf("Hello!\r\n");
    while(1) {
        wait(0.2);
        pc.printf("Bye!\r\n");
    }
}

After doing some digging, I found the following:

When the USB stack is initialized, the CDC-ACM driver calls USBD_CDC_ACM_Initialize() to run the user hook and initialize the UART, but it does not fully initialize the CDC-ACM driver's internal state until a USB reset event calls USBD_CDC_ACM_Reset()
In-between initializing the USB stack and connecting, any serial data received will be written to the uninitialized CDC-ACM circular buffer, triggering a bus fault when it tries to access 0x00000000.
This happens consistently on the STM32F103 HIC because it initializes the UART with a default 9600 baud configuration even before connecting over USB, whereas other HICs enable the UART without setting the baud rate.
On an LPC11U35 based HICs, this doesn't appear to be a problem normally. However, I can hang it if I increase the USB connection delay from eleven 90ms ticks to twenty, and applying my patch fixes that hang, so I suspect that it's still susceptible to the same issue, but it's just harder to send serial data that the partially configured UART will accept as valid.

I'm currently using this patch as a quick work-around:

 __weak int32_t USBD_CDC_ACM_Initialize(void)
 {
+    ptr_data_to_send = USBD_CDC_ACM_SendBuf;
+    ptr_data_sent = USBD_CDC_ACM_SendBuf;
     return (USBD_CDC_ACM_PortInitialize());
 }

Long-term, I think it might make more sense to not turn on the UART until a CDC-ACM set-line-coding request is received, since there's no telling what baud-rate the host expects anyways. Any data received before the line coding is set is potentially garbage.

Flash verification during programming

DAPLink should verify each block flashed by reading back the flash. This should either be turned on by default or enabled by a configuration value.

venv hides tools

Just putting this here because I think we had an idea how to fix it but I don't recall the solution.

Newest firmware for K64F does not function correctly with binaries with lots of debug

Jira bug

rev 0201 firmware works perfectly with the same binary, rev 0241 does not work at all.

transfer timeout

I'm attempting to create interface firmware for my custom platform (xDot) based on the Freescale KL17 processor. I have been able to build interface firmware, but it isn't able to flash the target processor. I enabled debug logging in the interface firmware and always get the same bunch of messages:

vfs_manager file_change_handler(name= Ax, file=200000a0, change=2)
vfs_manager file_change_handler(name=XDOT-T1BIN , file=200000c0, change=2)
vfs_manager file_change_handler(name=XDOT-T1BIN , file=200000c0, change=0)
vfs_manager transfer_update_file_info(file=200000c0, start_sector=37, size=38980)
file_to_program=200000c0
start_sector=37
stream=0
updated size=38980
vfs_mngr_periodic()
time_usb_idle=20160
transfer_state=1
state 2->1
transfer timeout
vfs_manager transfer_update_state(status=0)
file=200000c0, start_sect= 37, size=38980
stream=0, size_processed=0, opt_finish=0, timeout=1
Transfer finished, status: 4=The transfer timed out.
vfs_mngr_periodic()
time_usb_idle=2610
transfer_state=3
state 1->2

FAIL.TXT always says "The transfer timed out."

I had previously removed an interface chip from a kl43 dev board and put it on mine. This setup was able to successfully program the KL17 target. With that in mind, I used the KL43 flash algorithm from the FlashAlgo repository.

I'm not a JTAG/SWD expert and I'm not terribly familiar with the DAPLink codebase. I've spent time browsing the code and trying to trace back to where the error is coming from, but I haven't had any luck.

I built the bootloader using DAPLink repo and that works fine. I noticed that there are multiple binaries that get generated when I build the interface firmware

k20dx_xDot_if.bin
k20dx_xDot_if_crc.bin
k20dx_xDot_if_crc_legacy_0x5000.bin
k20dx_xDot_if_crc_legacy_0x8000.bin

I've been using the first one. Should I be using one of the others?

I don't think I have any major hardware problems since my device worked after I swapped interface chips. Does this look familiar to anybody? Can anyone explain in more detail what this error & series of log messages means? Does this point to my flash algorithm or target configuration, or something else entirely?

I've attached a diff of my changes from rev 8e14abb.
diff.txt

Ring buffer overflow is not properly handed in uart.c

When more data is written to UART ring buffer than its size is, it should not write more than it's size to USB. Buffer structutres cnt_in and cnt_out values must not be used to track how much data must be send to USB.

When buffer overflow is happening, oldest data must be overwritten with new one. When data is sent to USB, no more than buffer size must be sent.

Used project was k20dx_frdmk64f_if and DAPlink version 0242

RedBearLab BLENano fail.txt TIMEOUT

When I plug in the MK20 programmer (via USB) to my windows 10 laptop for the RedBearLab BLENano keeps mounting and dismounting. I can load the bootloader blenano_mk20dx_interface_20140912.bin provided by the https://developer.mbed.org/platforms/RedBearLab-BLE-Nano/, but when I try to load the nrf51822_blinky_nrf51822_.hex from here as well, the mount doesn't last long enough to complete the transfer. It was mentioned on the mbed forum that there might be a bug for the loader on windows 10. Has this issue been identified and corrected? Additionally, the fail.txt file say "TIMEOUT" is displayed on the drive.

Please see some additional details here:

uVision project cannot build

Sorry, this issue is about mbedmicro/FlashAlgo, and has been moved to pyocd/FlashAlgo#22

My env:

Python 2.7.12
progen 0.9.2
Keil MDK 5.17
ARM Compiler 5.06 update 1 (build 61)

As the README.md says, execute cmd:

$ progen generate -t uvision

then open project projectfiles\uvision\lpc4088\lpc4088.uvproj, try to build the target, log shows:

Build target 'lpc4088'

then MDK UV4.EXE collapses.

anything wrong?

Windows 10 host renders DAPLink useless

I'm facing a sporadic issue with DAPLink under Windows 10. Unfortunately there is no clear reproducible pattern, but it happens enough that it is really annoying. So hopefully this gives hints into identifying the issue.
I'm using DAPlink on multiple NXP boards (FRDM-K22F, FRDM-K64F and others based on the NXP K20 OpenSDA circuit). The problem is that Windows 10 seems to send packets to the DAPlink while it is in BOOTLOADER mode. These packets somehow are taken by the Bootloader as application files/data and it seems to start programming the application. But this of course does not work. As a result, the bootloader seems to overwrite itself: the board does not show up as bootloader any more.
The only solution/workaround is to re-flash the DAPLink bootloader with a debug probe.

The issue occurs whenever the DAPLink is in BOOTLOADER mode, sometimes it takes 10-20 seconds until it happens. The issue is easier to reproducible if the DAPlink microcontroller is in constant reset as I faced the issue much more often when I bring up a new target microcontroller (which stays in reset initially).

The same issue already exists with the original NXP OpenSDA bootloader (see https://mcuoneclipse.com/2016/08/01/bricking_and_recovering_opensda_boards_in_windows_8_and_10/). So I think the issue is the same for the DAPLink bootloader.

I hope this helps,
Erich

K64F with 0241 ASSERTS on usbc_msc.c

I am getting this kind of assert from 0241 K64F

Assert
File: ..\..\..\source\usb\msc\usbd_msc.c
Line: 1063
Source: Application

https://github.com/mbedmicro/DAPLink/blob/34182e2cce4ca99073443ef29fbcfaab9e18caec/source/usb/msc/usbd_msc.c#L1063

After this the device stops communication until it receives RESET.

This is relatively random event. I have observed it a few times during the last week. I using serial communication via Virtual Box from Win7 host and Ubuntu 16.04 client.

Multiple K64F flashing at the same time results on non functioning device

Jira bug

This might be linked to #94

Assert filenames missing from interface on Kinetis

Assert filenames were unintentionally disabled for both the interface and bootloader in #151 . They should only be disabled for the K20 and KL26 bootloader to safe space.

CC @flit