Support SWO trace.

[zxfeei]

CMSIS-DAP firmware needs to be version V1.10 or newer to support SWO trace. How to get version V1.10 or newer to support SWO trace?

[sbeling]

This is not supported in mbed yet, but would be very useful

[flit]

Well, first you need hardware that supports SWO. Not much point in adding the firmware support if the SWO signal isn't connected to the HIC. Which is why it hasn't been done yet.

[zxfeei]

In the future, will mbed DAPlink support SWO trace? When?

[jhgorse]

It looks like the NUCLEO- boards have T_SWO wired. I've started cracking at the -F429ZI board. It looks like there may be a k26f reference implementation. The main thing so far appears to be the need for the ARM USART Driver wrapper for the interface.

FWIW: https://github.com/jhgorse/DAPLink/commits/master

[flit]

That's correct. The SWO commands are supported now in the core CMSIS-DAP code. As long as you have a CMSIS USART driver for the HIC, it should be quite straightforward to enable. I think the Keil CMSIS-Packs for STM32 provide CMSIS-Driver implementations. See https://www.keil.com/dd2/pack/ to download packs (rename .pack to .zip to extract).

[jhgorse]

@flit Thanks for the tip! I just put that in there and now I'm crashing windows BSOD style. =)

I just had a realization and a moment of confusion. What are we forwarding the T_SWO information to? I can see that there are options to get back to the host:

1. CMSIS-DAP v1 HID,
2. CMSIS-DAP v2 libusb,
3. a secondary CDC, or
4. the SWO line of the interface chip (stm32f103cb in this case)

CMSIS-DAP v1 may have a bandwidth issue. I do not know the limits of HID, though I would suspect that may be an issue for 8+ MHz half-duplex serial in addition to debugging information.

Same with CDC unless arbitrarily high baud rates are supported host/client-wise.

SWO line of interface chip on NUCLEO is interesting. I think it could be possible to get to PB3 from JP1 and the intended function PWR-EXT. The downside being that it would require another debugger. That pretty much kills that idea.

So CMSIS-DAP v2 seems like the ideal transport.

Debug information from the debugger. It would make more sense for unit hardware testing and other application development processes needing a tight turnaround on target executed results.

Okay, back to the topic at hand. I filled out the RTE_Device.h to

• Adjust HSE from 25 to 8 MHz
• define RTE_USART1
• enable just the PA10 pin as RX for T_SWO connected to the target's SWO

Pretty reliably get windows 7 BSOD. Are there any ways to contain that more gracefully?

Cheers,
Joe

edit: BSOD occurs after flashing the Main Firmware for the interface-to-target in MAINTENANCE mode. I suspect as it attempts to re-connect.

It does appear to at least mount on OS X. Here is the contents of the DETAILS.TXT:

# DAPLink Firmware - see https://mbed.com/daplink
Unique ID: 079600010669ff565251887067052849a5a5a5a597969908
HIC ID: 97969908
Auto Reset: 1
Automation allowed: 1
Overflow detection: 1
Daplink Mode: Interface
Interface Version: 0253
Bootloader Version: 0254
Git SHA: da2470f07e2519232b4ba6239ae63adf84cb35f1
Local Mods: 1
USB Interfaces: MSD, CDC, HID, WebUSB
Bootloader CRC: 0x86710c6f
Interface CRC: 0xa6011e89
Remount count: 0
URL: https://mbed.org/device/?code=@U?version=@V?target_id=@T

CMSIS-DAP is dead as openocd can no longer interrogate the target.

Flashing an Mbed binary appears to copy to the MSC device, resets, then we get these files with a no longer running target:

ASSERT.TXT

Assert
File: ..\..\..\source\daplink\interface\target_flash.c
Line: 378
Source: Application

DETAILS.TXT is the same

FAIL.TXT

error: An internal error has occurred
type: internal