How to start and close Trace32 instances from t32start command line interface? - command-line

I have found out that Lauterbach Trace32 allows to launch Trace32 instances from the command line.
I have a ts2 file. I am trying to use the t32start.exe to start and close Trace32 instances. I have roughly tried the following:
t32start ts2_file_path -RUNITEM core_item_from_tree
However I am unable to close a Trace32 instance with the same. Can anyone tell me he correct way to open and close Trace32 instances?
Update
Sometimes, the GUI may have to be force closed, while the target is still running. (Perhaps because it is hung or the DAP configuration has failed).
In these cases, the following pop-up appears when restarting the GUI:
This prevents using Trace32, since remote access thereafter always returns communication failure. Is there any way to automatically have the target to reset (Press "yes"), by passing a flag to the trace32.exe command or otherwise?

Starting TRACE32 from command line:
T32Start is a tool which helps you to generate a TRACE32 configuration file and then launch the actual TRACE32 application for your target architecture family with that temporarily generated configuration file.
So to start TRACE32 you can either:
use that command line you've suggested to start TRACE32 via T32Start (which will only work on Windows)
generate a permanent configuration file and start TRACE32 directly with it.
The document "installation.pdf" in the PDF sub-folder of your TRACE32 installation tells you how to create a configuration file. You can also use T32Start to create a permanent configuration file like this:
Create the configuration you need with T32Start. Ensure to enable the "Advanced > Interfaces > API Port" for every core with a unique port to be able to close TRACE32 from command line later.
Then right click on a core (the node with a Lauterbach logo) and choose "Show Start Environment..." from the context menu.
The window, which then opens, has in the right bottom corner a button for "Save Batch Job As..." and one for "Save Config As...". Use those two buttons to save both files. Let's imagine you've saved the configuration under the name myconfig.t32.
Adapt the saved batch job so that the command line calling TRACE32 points to the configuration file. In the end you should have a line in the form t32m<cpu> -c <configfile.t32> -s <startscript.cmm>, where <cpu> is the short name of the CPU architecture family you are going to debug (like ARM, PPC, RISCV - you'll see it in the batch file). E.g. c:\t32\bin\windows64\t32marm -c c:\t32\myconfig.t32 -s c:\t32\mytestcase.cmm
Repeat steps 2 to 4 for all cores of your configuration, if you have an AMP multicore setup.
Merge all the saved batch files an use the batch file to launch all your TRACE32 instances. (Ideally wait a few seconds afters starting the first TRACE32 GUI).
Closing TRACE32 from command line:
Ensure to enable the remote API on all of your TRACE32 GUIs you'd like to close.
You'll find that setting in T32Start for each core node at "Advanced > Interfaces > API Port"
In the end, the configuration file for each TRACE32 GUI contains the following lines:
RCL=NETASSIST
PORT=20000
There must be an empty line before and after that block (while the block may also contain a line starting with PACKLEN=)
The value after PORT= defines a UDP/IP port and must be unique for every TRACE32 GUI.
If you have an open TRACE32 GUI with enabled API Port, you can send commands to it over the TRACE32 remote API. (See api_remote.pdf in your TRACE32 installation.) A command line tool which uses the remote API to send simple commands to a TRACE32 instance is t32rem.exe (you'll find it at the "bin/windows/" sub-folder of your TRACE32 installation).
Use t32rem as follows:
t32rem localhost port=<myport> <command>
For <myport> choose the port number you've used above in the configuration file after PORT=. For <command> use any TRAC32 command you'd like to send. E.g. the command QUIT to close the TRACE32 GUI.
However if you use QUIT for the TRACE32 command, t32rem will wait some time desperately for a response form the GUI you've just closed. To avoid that create a test file "quit.cmm" and put the following lines in that script:
WAIT 800.ms
QUIT
Then close the GUI via the command line:
c:\t32\bin\windows64\t32rem.exe localhost port=20000 "DO ""c:\t32\quit.cmm"" "
(The doubled double-quotes around the path of the CMM file are only require if the path contains blanks.)

Related

Capturing output from interactive, embedded terminal

I'm working on a Neovim plugin that's basically rich integration for an external CLI program. Users of this plugin would typically already be regular manual CLI users of this program. When my plugin needs to shell out to the CLI, I'd like to have the option to have that process run inside an interactive shell session in the embedded terminal. This puts the invocations into shell history, so they can easily be modified manually or looked up later.
I know I can send input to the terminal via its PTY channel but is there any way to access its stdout and exit codes, e.g. by attaching callbacks? Especially since the process would be running inside the interactive shell, not directly as the command passed to :terminal, I don't see an easy way to do it. Can't just read the buffer, and TermClose autocommands won't work.
I.e. is there a way I can implement something like plenary.job but have that job execute inside a currently running shell in embedded terminal?

run external process in integrated terminal without task

In an extension, I'm trying to implement a TextEditorCommand in response to which the document in the active editor is processed by an external program. I managed to do so by registering a function with the command, within which a Task object is created and executed:
in function activate:
vscode.commands.registerTextEditorCommand('extension.command', process);
in function process(textEditor):
const document = textEditor.document;
const task = new vscode.Task(
{type: ''},
vscode.TaskScope.Workspace,
extensionDisplayName,
extensionName,
new vscode.ProcessExecution(executable, [fileName].concat(args)));
vscode.tasks.executeTask(task);
This works, except that executing a task leads all open documents to be saved, which is unnecessary and may be unwanted; I only need the active editor document to be saved, which I can do myself.
Therefore my question: Is it possible to run an external process in the integrated terminal without a Task?
I checked whether I can execute the ProcessExecution on its own, without passing it to a Task, but that doesn't seem possible.
I also tried to directly create a terminal, but vscode.window.createTerminal does not provide the option to specify an executable, just a shell – though I might simply pretend that my executable is a shell?
Moreover, I already failed at creating any kind of terminal; putting
````typescript
vscode.window.createTerminal(extensionDisplayName);
````
into the `activate` function seems to have no effect whatsoever.
Turns out the transpiler process wasn't running, so my code never made it into the running extension.
I could simply use node's child_process.spawn, but then the process would not be attached to VS Code's integrated terminal.
Update: Specifying an arbitrary executable as the "shell" running in the Terminal works.
However, it seems currently impossible to keep the terminal tab open after the process ended, so a shell or another wrapper is necessary.
But then it's impossible to get the exit status of the actual (wrapped) process, except maybe by having the wrapper write it to the terminal and parsing it's text content... nah, impossible too. Ugh

eclipse for users to access from terminal(like putty)

Here in our institute we have a server where student login from putty and write code -- need to create a file and write code in vi editor(generally they copy and paste code into vi editor), also one can upload files by ftp transfer (using Ammy admin). Coding lang's can be Java,Perl, ...
Here we need a eclipse environment to individual user to access their code from putty. where individual must be able to run, debug his code on server for which he connected through putty.
This is to reduce the time for the students for working on 2 environments, and also to maintain assignments in sever according to user.
After you paste your code in Vi, you can run the program on server in debug-mode, with e.g.
java -agentlib:jdwp=suspend=y,transport=dt_socket,address=8123,server=y com.company.Main
and the program will listen on port 8123 until a debugger attaches to it,
and then you can remote debug it with Eclipse:
Run>Debug Configurations>double click "Remote Java Application">set project and host:port.
And you don't need putty for that, unless you are accessing the server through a ssh tunnel.
Eclipse do not support automatic code transfer to remote server, or starting program on remote server,
the program must be started from the shell as shown above, and then eclipse can attach to it.

Run Batch File Before Windows 7 User Login to Start VLC Web Interface

I would like to run a batch file I have that executes the following before a user logs on:
start "VLC web Interface" "C:\Program Files (x86)\VideoLAN\VLC\vlc.exe" -I http
Currently I have this in my Startup folder but I would like this batch file to be executed before a user is logged in on Windows 7. The goal is to start VideoLAN's Web Interface as a service without requiring a user to login. This way the computer can be turned on, and media can be streamed to my devices without choosing a user profile on the login screen.
To be clear, I would like this batch file to run BEFORE a user logs in, not after.
Any ideas?
The answer above would work. However, my preference of how to do it would be a little different. The effect is more or less the same, but I find it a little easier to use the Task Scheduler.
Open the Windows Task Scheduler.
Create a basic task.
Name it whatever you want, such as VLC Web Interface.
Click Next, and choose When the computer starts.
Click Next, and choose Start a program.
Click Next, and click Browse, then select your batch script.
Click Next, and click Finish.
It will now be in your Task Scheduler list of scheduled tasks. From there, you can right click on it and run it now, or end it, or whatever, and it will run every time the computer starts. Any user should be able to do this, whether on a domain or not, and even if you are using Windows Home (in which case you can't use gpedit.msc anyway).
Create a local group policy object for a startup script.
Start up scripts run pre login.
To create what you are after:
Open a run box
type in "gpedit.msc" (without the quotes)
Expand Computer Configuration
Expand Windows Settings
Select Scripts (Startup/Shutdown)
Double click Startup
Click Show Files and copy/paste your batch file in to this folder
Click the Add button on the startup properties
Click Browse and double click on your script to choose it.
"OK" out of all windows to apply the new settings.
The selected script will now run every time the PC starts.
If the PC is part of a Windows Active Directory domain these settings will be overridden with AD Group Policy, in which case the admin of the network should be doing this for you.
Edit:
It's been a few years since I wrote this, while this would work, it's probably simpler to go with Automate Everything's answer and use Task Scheduler to perform an "At Startup" action.

Remote debugging, creating a server

I'm following some WinDbg instructions from the CodeProject tutorial.
To start a server, I can get this to work from the command line fine:
WinDbg –server npipe:pipe=pipename
(note: multiple clients can connect).
Where do I enter this from the windbg UI? I tried the command browser window, but that didn't seem to do anything:
.server npipe:pipe=pipename
(note: single client can connect)
This question is related to creating the server from WinDbg UI, not connecting from the client.
I am assuming that you are referring to usermode debugging here, so I will respond with that in mind.
From windbg attached to your program that you want to remote:
If you want to use symbols that are cached on the target, then run:
from the Command Window's prompt type .server npipe:pipe=YourPipeName
If you have another machine with with a larger symbol cache, then on the target run:
dbgsrv -t tcp:port=4000
This sets up a thin debug client (a.k.a. remote stub)
Then on the machine running the debugger, open Windbg > File > Connect to remote stub
tcp:server= machine_running_dbgsrv ,port=4000
Now hit F6 and attach to the process you want to debug.
Note: the versions of windbg have to be the same on the machine running dbgsrv and the one running windbg. If they don't match, when you get to part where you hit F6, you end up with no processes in the process list.
Jason
File -> Connect to remote session. Or just use CTRL-R.