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?
amq
All 27 comments
CC @sg- @c1728p9 @bridadan
[Mirrored to Jira]
screamerbg
on 19 Apr 2017
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]
bridadan
on 19 Apr 2017
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]
sg-
on 19 Apr 2017
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]
bridadan
on 19 Apr 2017
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]
amq
on 19 Apr 2017
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]
sg-
on 19 Apr 2017
@amq Have your questions been answered?
[Mirrored to Jira]
theotherjimmy
on 28 Nov 2017
With an addition of SWO to mbed-os (https://github.com/ARMmbed/mbed-os/pull/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:
https://github.com/ARMmbed/mbed-drivers/issues/188
https://github.com/ARMmbed/mbed-trace/issues/67
https://github.com/ARMmbed/greentea/issues/23
[Mirrored to Jira]
amq
on 27 Feb 2018
J-Link detection was also just added to mbed-ls: https://github.com/ARMmbed/mbed-ls/pull/299
There's still work to be done in greentea and htrun though.
[Mirrored to Jira]
bridadan
on 27 Feb 2018
@amq Does this answer your question?
[Mirrored to Jira]
screamerbg
on 23 Mar 2018
@screamerbg the answer to my question is currently "a lot of progress has been made, but it's not possible yet".
[Mirrored to Jira]
amq
on 25 Mar 2018
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]
OmerRosler
on 21 Jun 2018
Check out my comment here: https://github.com/ARMmbed/greentea/issues/23#issuecomment-343935962
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]
theotherjimmy
on 22 Jun 2018
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]
bridadan
on 22 Jun 2018
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
on 9 Jul 2018
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]
RobMeades
on 13 Jul 2018
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.
desowin
on 28 Feb 2019
@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?
loverdeg
on 28 Feb 2019
@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.
theotherjimmy
on 28 Feb 2019
@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.
loverdeg
on 28 Feb 2019
@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.
theotherjimmy
on 28 Feb 2019
Final notes from my end on a related issue, https://github.com/ARMmbed/DAPLink/issues/577#issuecomment-460822443
And some possibly synergistic conversations
https://github.com/ARMmbed/DAPLink/issues/560
https://github.com/mbedmicro/pyOCD/issues/488
loverdeg
on 28 Feb 2019
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.
desowin
on 1 Mar 2019
We have implemented an htrun plugin for JTAG and SWD using JLINK commander.
Plesase comment in PR https://github.com/ARMmbed/mbed-os-tools/pull/150 if it does not resolve the htrun side of the issue.
embeddedteam103
on 26 Mar 2019
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.
ciarmcom
on 31 Oct 2019
I will be reopening this issue in the forum shortly. There was/is very obviously a lot of demand from experienced professionals.
loverdeg
on 4 Nov 2019
loverdeg
on 18 Nov 2019
Related issues
seankinghan
路
9Comments
wdwalker
路
10Comments
JanneKiiskila
路
7Comments
maclobdell
路
3Comments
AlessandroA
路
6Comments
Most helpful comment
@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.