In some cases, the Trace32 may hang, or may be closed while the target core is still running. This leads to the following screen when trying to reopen the Trace32 GUI:
Is there any way to force a "Reset and connect" (choose "Yes" in the popup) using the command-line, without requiring human interaction?
Short answer:
add the line
CONNECTIONMODE=AUTOCONNECT
to the PBI= section of you TRACE32 configuration file (usually "config.t32")
E.g.:
PBI=
USB
CONNECTIONMODE=AUTOCONNECT
Note: The block starting with PBI= must be embraced by empty lines, while there mustn't be empty lines within the block.
Detailed answer:
If you see that dialog box one of the following has happened:
You have started a second TRACE32 for an AMP multicore scenario, but the second GUI wasn't configured with CORE=2 or the first GUI wasn't configure for CORE=1.
You've started TRACE32, while another TRACE32 GUI is still exclusively connected to the same PowerDebug box.
You've started TRACE32, after the process or a TRACE32 GUI was killed (process removed from execution without proper closing the application).
You've started TRACE32, after a previous TRACE32 GUI crashed.
So in general you shouldn't see the dialog box and something went wrong, when it happened.
In case of issue 1 & 2 you should click NO, solve the issue as described below and then try it again. If you click YES, you will crash the already running TRACE32 GUI.
In case of issue 3 & 4 you could safely click YES, but anyway you should ensure that TRACE32 gets normally not killed (and crashes should be fixed by the Lauterbach support, I guess)
If you want TRACE32 to automatically "click" NO, to immediately close the new TRACE32 session, use the statement CONNECTIONMODE=AUTOABORT in the PBI= section of your TRACE32 configuration file (usually "config.t32"). (See also /pdf/installation.pdf)
If you want TRACE32 to automatically "click" YES, to force connection to the PowerDebug box by resetting it, use the statement CONNECTIONMODE=AUTOCONNECT in the PBI= section of your TRACE32 configuration file (usually "config.t32"). (See also /pdf/installation.pdf)
You can set this also in T32start, if you connect to you PowerDebug via Ethernet (e.g. PowerDebug PRO):
Note: In T32Start, this setting is only available if you connect to a PowerDebug via Ethernet (e.g. PowerDebug PRO). The setting CONNECTIONMODE=AUTOCONNECT/AUTOABORT works also with USB, but there, you have to add it manually to your TRACE32 configuration file.
And here is how to avoid the dialog box:
Case 1 "You have started a second TRACE32 for an AMP multicore scenario..."
For AMP multicore debugging with one TRACE32 GUI per core, please ensure that you setup a proper AMP scenario: Add the line CORE=n to the PBI= section of you TRACE32 configuration file (usually "config.t32"), where n must be 1 for the 1st GUI, 2 for the 2nd GUI, 3 for the 3rd GUI,...
If you starting TRACE32 via T32start.exe you have to set it up like that:
Case 2 "Another TRACE32 GUI is still exclusively connected to the same PowerDebug box"
Before starting a new TRACE32 GUI connecting to a PowerDebug box, please ensure to close all other TRACE32 GUIs you've started before (for the same box). You can do this from a system shell via t32rem.exe, if you know the remote-API port of the other GUI: t32rem localhost port=<API-port-of-GUI> QUIT (See also How to start and close Trace32 instances from t32start command line interface? on more details how to do that)
I am using TRACE32 R.2021 version. I have faced same issue like "TRACE32 device already used by other GUI"
I have added the following configuration in config_multicore.t32(Config file in my version of workspace)
CONNECTIONMODE=AUTOCONNECT
The issue got resolved.
Change the Connect Mode to Auto-Connect from Normal. Jtag should get reset on changing configuration
enter image description here
Related
I'm attempting to develop a coprocess plugin in python for iTerm2 but am running into some issues. I have a script that takes input from STDIN and sends it across the network to a listening daemon. This works fine when run from the command line, however when I activate the coprocess either via the menu or a trigger I just see a brief flash of the coprocess icon in the upper right corner. Googling does not reveal whether or not iTerm2 sends output anywhere that I can examine. I have looked at all of the system logs in Console.app but there is nothing there. I've also tried Toggling the Debug Logging in iTerm but I do not see any coprocess data in there. Anyone know if/where to find the STDOUT/STDERR of a coprocess script?
Stdin and stdout are hooked up to the tty as described in copresses documentation (and may be silent or visible depending on how it is set up). As for stderr, (judging by the lack of any redirect of fd 2 in Coprocess.m source) it is the same as stderr of iTerm2 itself. In order to see the error of copresseses, you can launch iTerm2 from Terminal in the foreground (open /Applications/iTerm.app/Contents/MacOS/iTerm2), interact with iTerm2, and view the stderr within Terminal.
My application is a GUI app that has helpful (though optional) information through the terminal (via cout).
In Windows I either have a console appear (by compiling as a console app, or allocating it dynamically) or I don't.
My intention is to make use of the console IF it is being run from the console, but ignore the console completely if it was not. (Essentially what happens in Linux and OS X).
I do not wish to redirect to a file (and in the case of using cin, this is not a viable solution anyway).
Is there a way to attach a GUI app in Windows to the console it is run from, if and only if it is run from a console?
and in the case of using cin, this is not a viable solution anyway
This is the killer detail in your question. It is simple on paper, just first call AttachConsole(ATTACH_PARENT_PROCESS) to try to attach to an existing console. That will fail when your program got started from a GUI program like Explorer or a desktop shortcut. So if it returns FALSE then call AllocConsole() to create your own console.
Using cin is a problem however. The command processor pays attention to your EXE and checks if it is console mode app or a GUI app. It will detect a GUI app in your case and then doesn't wait for the process to complete. It displays the prompt again and waits for input. You will then also wait for input but you'll lose, the command processor got there first. Your output is also intermingled with the command prompt, the easy problem to solve.
There's a simple workaround for that, your user should start your program with start /wait yourapp to tell the command processor to wait for the process to complete. Problem is: nobody ever uses that. And the user will not realize what happens when they type input, intending it to go into your program but it is actually interpreted by the command processor. Producing a mystifying error message or formatting the hard drive.
Only two good ways to solve this unsolvable problem. Either build your program as a console mode app and call FreeConsole() when you find out you want to display a GUI. Or always call AllocConsole(). These are not great alternatives. The first approach is the one used by the Java JVM on Windows. One of the oldest bugs filed against the JVM and driving Java programmers completely batty from the flashing console window.
The third alternative is the only decent one, and the one you don't want, create another EXE that will always use the console. Like Java does, javaw.exe vs java.exe.
A trick is possible, you can rename that file from "yourapp2.exe" to "yourapp.com". It will be picked first when the user types "yourapp" at the command line prompt, a desktop shortcut can still point to "yourapp.exe". Visual Studio uses this trick, devenv.com vs devenv.exe.
You can check CONSOLE_SCREEN_BUFFER_INFO (via GetConsoleScreenBufferInfo) on startup to determine if you've been run from within an existing console. If the buffer's position is 0,0, you were run from outside of the console. For details, see this Microsoft Knowledgebase Article which describes the process.
In order for this to work, you need to compile your application as a console application (using /SUBSYSTEM:CONSOLE), and then detach yourself from the console if the application started a new console (buffer at 0,0). This will cause the program to properly "attach" to the calling console when launched from a command line.
As others have pointed out you have to create a console app and a window app. So, you'd end up with console.exe and app.exe. To make it less obvious at the command-line, you can take advantage of the PATHEXT trick like devenv does. cmd.exe treats a file as a command if its extension is in the PATHEXT environment variable. COM is there by default so you could rename console.exe as app.com, allowing the command app to start the console app attached to the current console.
Note: Of course, a console app can show a GUI if desired.
The difference in the build between app.com and app.exe depends on your build system but it could just be the one attribute that sets the output type. With msbuild (for .vcxproj files), it's just a matter of another build configuration.
you can create an application in console that get a line using argc and prints it;
////
int main(int argc, char *argv[])
{
//here print argv....using cout or printf
}
save the file as console.exe in the folder of your app.
now in your app if you want to see any line in console you can call the command
system("console.exe this is the line i want to print and see in console");
I want to make some debug console for my application. It should output some data and take input commands. How can I do this? The best way is updating console like: drawing information and prompt for input after the data.
I'm developing under Linux. For example, gdb could take input from console.
If you're familiar with socket programming (or actually, any other kind of IPC mechanism), you might want to enable some listener within your application, and develop an external application that will do all the "console" stuff for you, while communicating with the main application.
Let's suppose you have an application that has a single button and a single text label, and every time you press that button - the text label goes up by 1, from 1 to 2 to 3 etc.
You can build a socket listener into that application. When the socket listener accepts a new incoming connection, you'd start a connection thread that can:
Receive a "shutdown" command
Receive a "reset counter" command
Send an update regarding the current count on every click
etc.
Then you build another, external application, which connects to the main application, and sends messages to it, based on console input it gets from the user. It would also listen to incoming updates and show them to the user.
Using an external application for debug-controlling your main application is extremely helpful, with the following reasons being some of the advantages:
No matter how the debug application is buggy, it cannot hurt the release version of your main application.
All the code that deals with the console management, which is redundant to your main application, can be kept outside of the main app.
Making two projects out of it can make it easier to collaborate your work with someone else, as long as you are both aware of the protocol between the two sides.
Implementing what I suggested means you can debug your application remotely, in case you don't have access to the main application (for example, if it's on a customer site).
How can i programatically check if the windows shell (explorer) has loaded all startup programs & the user login process is over ?
There is a somewhat documented event you can wait for, but it is signaled when explorer has started loading. On XP this event is called "msgina: ShellReadyEvent" and "ShellDesktopSwitchEvent" on Vista. I linked to the sources of some alternative shells in a post related to this event.
Another alternative would be to listen for the Taskbar Creation Notification message. It can fire more than once so you would need to keep track of that.
On Vista+ there is one last alternative that might just work: Programs set to run at startup are part of a job object so they cannot run at high priority. If your program runs at startup you could maybe check for this, either by using IsProcessInJob or SetPriorityClass+GetPriorityClass in a loop. (SetPriorityClass will lie about its return value IIRC)
I have a situation that has been partially covered by other answers at SO, but I cannot find a complete answer. In short, we are trying to use URL's for our specific data types that when double clicked will open up our application and load those data sets into that app. We have this part working.
(for example, an URL might look like this: resource://shaders/basic_shader.hlsl)
What we would like to do is to prevent new instances of the application from opening when a new URL is double clicked. For example, let's say we have a URL that opens up a shader in our shader editor. When clicking this resource URL, it will open our shader editor. When a new shader URL is clicked, we'd like to be able to open up the shader in the currently running application and have it open up the new shader in a new tab in our editor.
We can easily detect if another instance of our application is running. The problem that we don't know how to easily solve is how to tell the currently running application to open up this new file for editing. This behavior is very much like the Apple Finder.
In unix, you could emulate this behavior by having your application open some named pipe and then new apps could check if this pipe is active and then send the document data down the pipe. Is there a more standard windows way of achieving this behavior?
We need a C/C++ solution. Thanks.
Named pipe is the best way.
First instance of your application opens the pipe and listens to it (use PIPE_ACCESS_INBOUND as dwOpenMode and the same code will also allow you to detect running instances).
All subsequent instances check that they are not alone, send command line argument to the pipe and shut down.
Create a named mutex when application launches as David Grant said, then before displaying the UI for the second URL, check for this mutex, if it is already created then just quit by passing the new URL to the first launched application (Have interface in the application to set the URL and tell to redirect programatically)
You can't avoid the program associated with the url to be executed.
The "windows" solutions would be to send a message (via DDE in the old days but maybe there is something more "modern" now) to the previously running application with the url then quit ...
You can acquire a named mutex upon startup and enforce it that way.
http://www.google.com/search?hl=en&q=named+mutex+single+instance
CreateMutex on MSDN
I got this working pretty well for my C++ MFC application by following Joseph Newcomer's tutorial here. He uses a named mutex that is checked on startup and a message sent to the already-running application with the new resource to be opened.