How to run tests over SWD?

[amq]

Custom boards may choose not to include mbed-HDK / CMSIS-DAP, but still enjoy proper debugging over J-Link / SWD. Is it possible to run mbed tests in such case?

[screamerbg]

CC @sg- @c1728p9 @bridadan
[Mirrored to Jira]

[bridadan]

Currently we don't have a way to do this, and I don't believe it's a priority at the moment. @c1728p9 Did you ever do any experiments with running tests purely through the debug channel?
[Mirrored to Jira]

[sg-]

If the debugger (SWDAP for instance) is target aware and detectable by mbed-ls it should work. Other than SWD there is a requirement for UART to run the mbed tests.
[Mirrored to Jira]

[bridadan]

If the debugger (SWDAP for instance) is target aware and detectable by mbed-ls it should work. Other than SWD there is a requirement for UART to run the mbed tests.

True, if your debugger allows you to program your device by copying binaries onto a Mass Storage Device and mbedls correctly identifies the device, then it should flash ok. But then you will still need the UART channel like you mentioned @sg-.

I took the original question to mean using a traditional SWD/JTAG debugger that only exposes a typical debug channel like CMSIS-DAP or something, not the extra Mass Storage Device and UART endpoints that we provide as part of the mbed-HDK/DAPLink.

@amq If your debugger supports the Mass Storage Device, is identified by mbed-ls, and you have an external UART channel set up, then you will need to tell mbedls where to find that UART channel. You can use the "retarget" functionality of mbedls to do this, which is documented here: https://github.com/ARMmbed/mbed-ls#example-of-retargeting
[Mirrored to Jira]

[amq]

Did you ever do any experiments with running tests purely through the debug channel?

I'd like to do that, just need some starting point.

I took the original question to mean using a traditional SWD/JTAG debugger that only exposes a typical debug channel like CMSIS-DAP or something, not the extra Mass Storage Device and UART endpoints that we provide as part of the mbed-HDK/DAPLink.

That's what I meant, a board without Mass Storage and UART, just with SWD/JTAG.

The main point of my question is: I'm in a process of creating a product/board running mbed-os, and I need to understand if implementing mbed-HDK is necessary.
[Mirrored to Jira]

[sg-]

The main point of my question is: I'm in a process of creating a product/board running mbed-os, and I need to understand if implementing mbed-HDK is necessary.

There needs to be the existence of an mbed interface available for the board, so yes. Why would you not provide the USB composite functionality and add the UART pins? https://www.mbed.com/en/about-mbed/mbed-enabled/mbed-enabled-program-requirements/#mbed-enabled-for-mbed-os-5

I'd like to do that, just need some starting point.

This would require semi-hosting (intrusive and not necessarily ideal or practical) or something like a re-targeted DCC and a host-side tool.
[Mirrored to Jira]

[theotherjimmy]

@amq Have your questions been answered?
[Mirrored to Jira]

[amq]

With an addition of SWO to mbed-os (ARMmbed/mbed-os#5956), my goal seems to be a step closer.

To recap, I'm trying to do:

• flash the device using J-Link, basically, just run JLinkExe -commanderscript firmware.jlink
• execute the tests with SWO / semihosting

Related:
ARMmbed/mbed-drivers#188
PelionIoT/mbed-trace#67
ARMmbed/greentea#23
[Mirrored to Jira]

[bridadan]

J-Link detection was also just added to mbed-ls: ARMmbed/mbed-ls#299

There's still work to be done in greentea and htrun though.
[Mirrored to Jira]

[screamerbg]

@amq Does this answer your question?
[Mirrored to Jira]

[amq]

@screamerbg the answer to my question is currently "a lot of progress has been made, but it's not possible yet".
[Mirrored to Jira]

[OmerRosler]

I am willing to take the time and effort to fully implement this feature.
Is there a road-map/direction to get started?
[Mirrored to Jira]

[theotherjimmy]

Check out my comment here: ARMmbed/greentea#23 (comment)

You would need to implement a flash plugin and @bridadan and I will have to provide steps to redirect the "serial" over SWD. I'm looking into it now.
[Mirrored to Jira]

[bridadan]

My understanding of serial over SWD is that it is only unidirectional (from the MCU to the host pc). Is this correct? If so, that would currently break a lot of the tests within the Mbed OS test suite. Many of them require back and forth communication.
[Mirrored to Jira]

[RobMeades]

FYI, I am also interested in this as I have exactly the same use case. My board has our NINA-B1 module on it, which provides only one serial port that is already connected to another device on the board (a cellular modem) hence it is unavailable for testing. I have an SWD connector through which I can flash the NINA-B1 module and reset it (using the hooks in host_test_plugins) and I have the SWO pin to which I am able to redirect stdout. The issue is getting stdout into Greentea. I was planning to write a wrapper around Segger's JLink SWO app to make it appears as a virtual COM port and fake the "sync" response but a better solution would be preferable.
[Mirrored to Jira]

[RobMeades]

Further FYI, I've tried using the stdio redirect feature to get stdio to appear on SWO, which works really well, however Greentea uses RawSerial to talk directly to the serial port and so redirecting to SWO in this way doesn't help. I don't think I can get any further without significant Greentea surgery to abstract the transport.
[Mirrored to Jira]

[desowin]

If the GreenTea transport is abstracted to not use RawSerial directly, then one possibility would be to use SEGGER RTT on JLink targets. SEGGER RTT is released under BSD-3 Clause license. SEGGER RTT requires only a small memory buffer to work and no other hardware. SEGGER RTT allows bidirectional transfer, so also the mbed tests that @bridadan mentions could work just fine.

Bsides that, I would really like if it would be possible to provide application's own flash/run/... python functions for the custom target defined in custom_targets.json. That way, it would be possible to make all the tools working with any debugger probe.

[0Grit]

@RobMeades been wondering if SWO was a possibility.

@bridadan
Any reason this wouldn't be a feasible solution if the surgery were completed?
Can the current efforts underway in https://github.com/ARMmbed/mbed-os-tools be used as an excuse to address this?

[theotherjimmy]

@desowin Thanks for the links and insight. That's very helpful

@loverdeg-ep We're thinking about using the debugger more often for flashing, so it should be possible to use it for bidirectional communication as well. I'm not sure we have plans to address this, but I'm also not entirely sure what "it" was referring to in that sentence.

We could make the "backend" to GreenTea Client configurable through mbed config, and then it would be possible to use --app-config use-rtt.json (name meaningless, there for the sake of letting you know what that app config does) to build all tests to use rtt. Then you could explicitly do something with mbed test --run so that it assumes RTT. That's something we could probably implement quickly.

[0Grit]

@loverdeg-ep We're thinking about using the debugger more often for flashing,

@theotherjimmy Glad to hear it. We've found ourselves in situations where we are wanting to run greentea tests but might not have MSD flashing available. Seems to be the more convenient route anyways.
Might also see this being useful if daplink ever ends up supporting secure/authenticated swd scenarios.

This would also give us some flexibility in our trial uses of FT4232H as an interface for SWD, monitoring of multiple serial peripherals, and target testing.

[theotherjimmy]

@loverdeg-ep We recently looked into testing htrun as a black box and found that there are 7 seconds of BLIND WAIT for each test, probably because it worked with the waits. The reason for that is that we don't have great feedback about when a target has finished flashing and reset completely, which we could have with a debugger connected.

So we have more than one reason to pursue using the debugger for everything.

[0Grit]

Final notes from my end on a related issue, ARMmbed/DAPLink#577 (comment)

And some possibly synergistic conversations
ARMmbed/DAPLink#560
pyocd/pyOCD#488

[desowin]

One of the advantages for flashing using debugger is the possibility to also flash external flash memories like QSPI. For example the DISCO_F746NG has external QSPI memory on board. The MSD on that particular board does not accept the hex file and thus it is not possible to program the QSPI flash memory on that board using current mbed tools.

ST-Link Utility contains the memory loader for the QSPI flash, so you can easily program hex file (that holds both internal flash and QSPI memory data) using the ST-Link Utility.

SEGGER has released the STLinkReflash utility that allows to modify the onboard ST-Link into JLink OB. Unfortunately the JLink OB (on reflashed ST-Links; as of 1st March 2019) comes without the Drag'n'Drop programming (so no MSD => not detected by current mbed tools). However, the JLink commander is capable of flashing the hex file that contains both internal flash and QSPI data. Similarly, in SEGGER Ozone debugger you can open the elf file and simply download elf sections (internal flash and QSPI) to the target.

[embeddedteam103]

We have implemented an htrun plugin for JTAG and SWD using JLINK commander.

Plesase comment in PR ARMmbed/mbed-os-tools#150 if it does not resolve the htrun side of the issue.

[ciarmcom]

Thank you for raising this issue. Please note we have updated our policies and
now only defects should be raised directly in GitHub. Going forward questions and
enhancements will be considered in our forums, https://forums.mbed.com/ . If this
issue is still relevant please re-raise it there.
This GitHub issue will now be closed.

[0Grit]

I will be reopening this issue in the forum shortly. There was/is very obviously a lot of demand from experienced professionals.

[0Grit]

https://forums.mbed.com/t/swo-for-greentea-tests/5857