Hi, I am debugging projects for the LPCXpresso1769/CD board (rev. D) with the LPC-Link2 probe (with the CMSIS-DAP firmware). I have tried to enable the SWO Trace, but to no avail.
According to the board datasheet, the 10 pins SWD connector on target PCB board includes the SWO signal, connected to pin # 1 of the MCU:
But that pin is not an I/O pin, configurable through PINSEL registers. I can't configure it in any way, at least that I know of. In the user manual (UM10360) there is also no reference to any way to configure the SWO pin: no related register, no trace clock, nothing ... Just the pin description: "Serial Wire Output. The SWO pin can deliver Serial Wire Viewer data only. Serial Wire Viewer data includes ITM and DWT trace data."
In such a way that at first I assumed that it would be an automatic connection. In the debug options I verify that the SWD connection is established. And in SWO Trace Configuration I specify the target clock speed. It doesn't give me any error, but only the lights corresponding to SWD connection and clock speed come on.
I have read a lot of forum messages (none related to the LPC17xx family, except one that did not use the LPC-Link2 probe), and seeing how complicated it can be to enable the SWO Trace, I draw the conclusion that it is not supported with the LPCXpresso1769/CD board. But I would like someone to confirm it for me.
Or, on the contrary, if someone has handled the SWO Trace with some MCU of the LPC17xx family, I would appreciate if you could explain to me how you configured it.
Thank you.
Thanks for the prompt reply, @KalaimaniArumugam. I tell you my doubts:
1) The document "LPC-Link2 Debug Probe Firmware Programming" does not demonstrate that the LPCXpresso1769/CD board is compatible with SWO Trace. It simply says that the default CMSIS-DAP image provides support for SWO Trace capture from the MCUXpresso IDE, as long as the 'Non Bridged' variant of CMSIS-DAP is not used (which is what I understand you want to point out to me by mentioning the points 4.1 and 7.2). But it also says, for example, that it supports Power Measurement from the MCUXpresso IDE; however, it is a feature that the LPC1769 does not include.
Well, I know in theory it should be compatible. If we look at the document "MCUXpresso IDE SWO Trace Guide" (rev. 11.3.0 of April 2, 2021) we can read, among many other things (sorry for extending me, but I want to make clear the aspects that I have taken into account):
- The Serial Wire Output (SWO) tools provide access to the memory of a running target, and facilitate Trace without needing to interrupt the target. Support for SWO is generally provided by all Cortex-M3 and M4 based MCUs. It requires just one extra pin in addition to the standard Serial Wire Debug (SWD) connection (but cannot be used if a JTAG debug connection is being used) [p. two].
- MCUXpresso IDE’s SWO Trace functionality can be used with all supported debug solutions, however SWO requires connection to the target MCU using a compatible debug probe such as LinkServer LPC-Link2. Note: SWO cannot be used with other CMSIS-DAP based probes or with LPC-Link2 debug probes using the non default Non Bridged (NB) or Serial (ser) firmware [p. 1].
- Due to the way the Trace data is transferred by the Cortex CPU within the MCU, setting the correct clock speed within the SWO Trace interface is essential to determine the correct baud rate for the data transfer. The first time Trace is used in a project you will be asked to enter the target clock speed. SWO Trace attempts to read the clock speed from the SystemCoreClock global variable and will suggest that value if found. The SystemCoreClock is usually set to the current clock speed of the target. Take care to use it after the application has set the clock speed for normal operation, otherwise it may provide an inappropriate value [p. 4].
- Most MCUs should not need any special configuration to use SWO Trace. [p. 4]. The document then mentions families that require special configuration, which does not include the LPC17xx family.
However, on page 1, and that is what raises my doubts, it also says: "Important Note: SWO debug features will only be available if supported by the target MCU, target board and the project being debugged has correct pin muxing and clock setup [p. 1]".
As I mentioned in my original message, in the LPC1769 documentation, in relation to the SWO Trace, only the existence of the SWO pin is mentioned, without any additional explanation or any configuration option.
Regarding the board, in the document "MCUXPresso IDE SWO Trace function" (retrieved from ) it is emphasized that "in order to support the SWO trace function, the 10 pins SWD connector on target PCB board must include the SWO pin" [p. 1], which is what I was trying to demonstrate with the image of the original post. And then it explains how to configure the MCU by software to be able to use the SWO Trace (it gives as an example the LPC54618). On the LPC1769, however, nothing can be configured (at least I miss it).
2) Correct. Automatic clock speed detection works fine.
As I said, at first I thought that the configuration would be automatic: "Most MCUs should not need any special configuration to use SWO Trace". My doubts about the configuration arose because the SWO Trace does not work for me:
In the aforementioned document "MCUXPresso IDE SWO Trace function", in countless forum posts, and in not a few MCU on Eclipse blog posts, the configuration to use the SWO trace is not trivial: configuration of the SWO pin, the SWO divider Clock, more configuration of not a few registers ...
However, no mention of the LPC17xx family. It could only means two things:
- There is no need to configure anything. But then why doesn't it work for me?
- The SWO Trace is not supported.
That is why I decided to ask in the forum.
3) "LPC-Link2 work well LPCXpresso1769/CD with trace option". Sorry to insist, but when you say that the trace option works well with the LPCXpresso1769/CD, are you referring to a theoretical question, or have you really tried it?
If so, I would appreciate any hints as to what I may be doing wrong.
Thank you very much.
Asier
