[Bug]: pyOCD reports errors, despite the fact that tests are working just fine

[ReinhardKeil]

Description

pyOCD v0.44.1

https://github.com/Arm-Examples/ModelNova/actions/workflows/Run_RPS_AppKit-E8.yml

Show content of pyocd.out

Run cat ./pyocd.out
0001437 W Skipping CoreSight discovery for AHB5-AP@0x40000 because it is disabled [ap]
0001746 I RTT channel 1 configuration for core 0: mode=systemview [rtt_manager]
0001747 W RTT for core 1: no channels configured; RTT disabled [rtt_manager]
0001749 I Run server started for M55_HP (core 0); STDIO mode: console; RTT: enabled [run_cmd]
0001749 I Run server started for M55_HE (core 1); STDIO mode: off; RTT: disabled [run_cmd]
0001754 E Error reading RTT up channel 1: SWD/JTAG communication failure (WAIT ACK) [rtt_server]
0001754 E Error reading from RTT channel worker 1: SWD/JTAG communication failure (WAIT ACK) [rtt_server]
0001755 E Error writing RTT down channel 1: SWD/JTAG communication failure (WAIT ACK) [rtt_server]
0001762 W Target core 1 unexpectedly halted at pc=0x00000ed2 [run_cmd]
0031778 I Time limit of 30.0 seconds reached; shutting down all Run servers [run_cmd]
0031789 I SystemView: SVDat file '/home/devuser/actions-runner/Arm-Examples/_work/ModelNova/ModelNova/RockPaperScissors/AppKit-E8_USB/out/SDS+AppKit-E8-U85.SVDat' generated [systemview]

[RobertRostohar]

SWD/JTAG communication errors are actually happening while reading the RTT memory. On Alif E8 they typically seem to sporadically occur after the target is reset and starts executing. The processor stubs programmed with the Alif SE tools also have an impact on this.

I would leave them as they are since they indicate real communication issues and we should not suppress them.

[ReinhardKeil]

Questions:

• How do I know that these errors are uncritical? Should they just become warnings?
• Message are inconsistent
• Connect messages better to the configuration settings (https://github.com/Arm-Examples/ModelNova/blob/main/RockPaperScissors/AppKit-E8_USB/SDS.csolution.yml#L46)

Current:

0001746 I RTT channel 1 configuration for core 0: mode=systemview [rtt_manager]
0001747 W RTT for core 1: no channels configured; RTT disabled [rtt_manager]
0001749 I Run server started for M55_HP (core 0); STDIO mode: console; RTT: enabled [run_cmd]
0001749 I Run server started for M55_HE (core 1); STDIO mode: off; RTT: disabled [run_cmd]
0

Proposal:

0001746 I RTT for M55_HP (core 0): channel 1 mode=systemview [rtt_manager]
0001747 I RTT for M55_HE (core 1): disabled [rtt_manager]
0001749 I Run server for M55_HP (core 0); telnet mode: console; RTT: enabled [run_cmd]
0001749 I Run server for M55_HE (core 1); telnet mode: off; RTT: disabled [run_cmd]
0

Note: I'm open to rename telnet into stdio (but this would need investigation of the implications).

[RobertRostohar]

How do I know that these errors are uncritical? Should they just become warnings?

They should stay errors since they indicate problems that can become critical.

A single error on startup (after reset) or a few sporadic errors are typically not critical. RTT buffers are continuously read. If an error occurs in one iteration, then that iteration is abandoned but the RTT processing continues. When there are just a few sporadic errors, then the RTT processing is still working but the effective bandwidth is decreased. If errors cause issues depends on what the RTT is being used for. In this example it is being used as a transport mechanism for SystemView messages. Decreased bandwidth could lead to overflow of SystemView messages.

To summarize, occasional communication messages should not be critical. However, they indicate certain issues with the target or debug link.

In case the errors persist, then typically also RTT processing will effectively not be working properly anymore.

[RobertRostohar]

Messages are inconsistent

The main issue is that telnet node name is not really the best choice as I have outlined already in the past.

CSolution project telnet: node:
Is used for STDIO, similar as the description says "Telnet service for character I/O".

Term 'telnet' is however more generic and there are various but similar descriptions:

• networking protocol and command-line utility used to interact with remote computers or devices via a text-based interface.
• network protocol and command-line tool used to connect to another computer over a network and interact with it remotely.
• client-server application protocol that provides access to virtual terminals of remote systems on local area networks or the Internet.

We have intentionally chosen the format in pyOCD regarding RTT and STDIO (telnet) shown below.

Configuration example

telnet:
  - pname: M55_HP
    mode: console
rtt:
  - pname: M55_HP
    channel:
      - number: 0
        mode: stdio
  - pname: M55_HP
    channel:
      - number: 1
        mode: systemview

I RTT channel 0 configuration for core 0: mode=stdio [rtt_manager]
I RTT channel 1 configuration for core 0: mode=systemview [rtt_manager]
I Run server started for M55_HP (core 0); STDIO mode: console; RTT: enabled [run_cmd]
I Run server started for M55_HE (core 1); STDIO mode: off; RTT: disabled [run_cmd]

The first two info messages indicate the channel configuration which is consistent with the configuration rtt: channel::mode:

• stdio: Connects channel to standard input/output service that is configured via the telnet node.
• systemview: Saves channel data to *.SVDat file for SEGGER SystemView tool.

The next two messages indicate that a Run server was started per core with run information specific to that core (STDIO and RTT)

• core 0: processes STDIO (for console) and RTT
• core 1: does not process STDIO or RTT (only core state)

We have intentionally chosen STDIO instead of telnet since it describes the actual usage and is less confusing.

Also, the format of the message (example: 'RTT channel' at the beginning) is used consistently also for other messages.

IMHO the telnet node should be named better to reflect that it is actually for STDIO. telnet:mode:console is confusing. It is used to specify that the STDIO is routed to console.

Alternative names for telnet could be terminal, stdio, ...

[ReinhardKeil]

Two items:

• In a CI system, an error always triggers an alert (and actually should stop the test)

I'm ok with the channel in front, just found it strange that the core name is not consistently included. Also why is there a warning when RTT is not assigned.

I RTT channel 0 for M55_HP (core 0): mode=stdio [rtt_manager]
I RTT channel 1 for M55_HP (core 0): mode=systemview [rtt_manager]
I Run server started for M55_HP (core 0); STDIO mode: console; RTT: enabled [run_cmd]
I Run server started for M55_HE (core 1); STDIO mode: off; RTT: disabled [run_cmd]

I agree that telnet should be renamed; stdio is my preference.

[RobertRostohar]

In a CI system, an error always triggers an alert (and actually should stop the test)

OK, in the light that the error does not stop the 'pyocd run', let's see if we can convert it to a warning without effecting the framework when used outside the run command.

Also why is there a warning when RTT is not assigned.

Most likely can be removed (we'll check).

I agree that telnet should be renamed; stdio is my preference.

I would also go with stdio.