I am using Lauterbach debugger (TRACE32 interface) on a 7447 processor. I need to load multiple files onto this processor which I do by running commands in the T32 GUI. Idea is to have a script do the job. One way is to call individual .cmm files in the startup.cmm. But this encounters a problem each time the GUI pops-up a dialog box which again requires a manual input. Can anyone tell me how to use command line interface on T32 to achieve the same?
A target program is normally loaded to your CPU's memory with the command
Data.LOAD.Elf myprog.elf
However TRACE32 deletes the symbol data base every time you use Data.LOAD.Elf before loading your new target program. To suppress that use option "/NoClear".
So if you want to load more than one ELF (target program) to your CPU's memory you should do it like this:
Data.LOAD.Elf myprog1.elf
Data.LOAD.Elf myprog2.elf /NoClear
Data.LOAD.Elf myprog3.elf /NoClear
If you use the Data.LOAD commands in one *.cmm script file or in several *.cmm script files is up to you, but I would put it one cript.
A dialog box should not pop-up.
In case someone still needs an answer.
My script to load elf file:
flash-elf.cmm:
local &fileName
entry &fileName
print "LOAD &fileName"
IF (!FILE.EXIST(&fileName))
(
PRINT "No elf file was flashed"
ENDDO
// T32 will stay opened
)
DO ~~/demo/powerpc/flash/mpc574xg.cmm "PREPAREONLY" // you should choose your cpu script
FLASH.ReProgram ALL
Data.LOAD.Elf &fileName
FLASH.ReProgram off
SYStem.ResetTarget
GO
QUIT
save it either in you home directory (or bin, or any directory that PATH points to) or even next to t32.config (where T32 installed, that's what I use)
now from CMD I call
t32mppc.exe -s ~~/flash-elf.cmm my.elf
Here's an answer on how to control T32 via TCP/UDP
https://stackoverflow.com/a/39400777/4875690
I have faced the same problem and finally, I have figured out that the popup dialog box has been created from the PRACTICE Script (.cmm).
So just check out your PRACTICE Script (.cmm) and remove the code that is creating the popup dialog box.
The below code is an example for the code that creates Yes/No dialog box from a PRACTICE Script (.cmm)
LOCAL &result
DIALOG.YESNO "Program FLASH memory?"
ENTRY &result
IF &result==FALSE()
ENDDO
PRINT "User clicked Yes."
The above example is from here (https://www2.lauterbach.com/pdf/ide_ref.pdf).
For controlling trace32 via the command line, please check out this (controlling trace32 via command line).
Related
This is kind of an odd question but does anyone know how to make a c++ program open multiple separate CMD prompts? they don't even have to be proper command prompts they can spit out text in a separate CMD like window that's fine. they don't need to talk to each other or do anything more than display text. the only reason I'm not doing this in Batch is because it needs to be a compiled EXE. I know I can run windows commands in c++ with "system(...)" however I'm not sure how to force these to be separate windows. if anyone knows a way to do that I would greatly appreciate it.
Thank you for your time
You can use CreateProcess to rum cmd,and communicate through pipe.
Your question is not clear to me, but let me try:
A single process can have no or exactly one console window. E.g. in Visual Studio, in the linker settings, you can set the subsystem to console, then the console window is opened automatically or you can use AllocConsole to get one. If you need more windows to display text, you have to create these windows by yourself (these windows aren't normal console windows). Another possibility is to start more backgroud processes, each having its own console window to display the text. To start these background processes, use CreateProcess and use for dwCreationFlags CREATE_NEW_CONSOLE.
If you have a batch file and want to display multiple console windows, use the start command to start your console program to create a new console and disply its output there, e.g.
start cmd.exe /k dir
I have a SAS program I would like to schedule, so we don't have to run it manually.
In the program we call an excecutable (reg.exe), like this:
X CALL "K:\reg.exe";
The executable opens a standard windows save-dialog and all we need to do is press save, which will save an xml-file. The save-dialog already opens in the correct directory.
What I would like is to somehow pass the instruction on, using code, to "press save", so the program can move on and work with the saved xml-file.
Is this possible somehow?
Thanks for your help!
Thomas:
There are numerous Windows utilities for scripted control of an interactive program. For example: AutoIt (my favorite), MouseRobot and AutoHotKey to name a few.
The statement
options xmin noxwait noxsync;
will cause the external program to run, not wait for the command session to exit, and not wait for the command to complete.
If your SAS programs needs to wait for the side effects of the scripting use of reg.exe to occur before occurring, use:
options xmin noxwait xsync;
These settings affect other operating system interfacing features, such as:
X command
CALL SYSTEM routine
%SYSEXEC statement
The use of your reg.exe might require your login to have admin rights.
The SYSTASK statement can also run external commands.
If you find that you are unable to run external commands, it is probably because the system setting NOXCMD is active. This setting is on by default in SAS server environments.
I'm using System function System(mypath/test.xls) to open and edit an excel sheet in C++ run time. It opens my excel sheet, allows me to edit ans close the same. After closing the excel sheet, the control goes to the code again. Everything works fine unless there is already some other excel sheet opened. If there is some other excel sheet already opened in the machine, I will not able to edit and close so that control goes to code. Can anyone suggest any solutions for this issue.
What is happening is your System(..) function call is asking the Windows shell to find the application associated with your file (test.xls) , which is Excel. Then if Excel is already running it is asked to open file. If the application is not running, then Windows starts the application for you.
So if the application is not already running and it is started for you it becomes associated with your program as a 'child' process. Therefore your System(..) call waits for it to end before continuing. If however Excel is already running then once Windows informs that instance of your desire to open the file test.xls, your call to System(..) returns immediately.
You can avoid this by explicitly running the Excel program by giving the full path to the Excel EXE file. And including the /x command line argument and full path to your file. The /x causes Excel to open a new process and then open your file. This new process is a child of your program's so the System(..) call will wait..
I'm not familiar with the System(..) call (is it like the system(..) one?) you may have to provide the switch /x, and path arguments as distinct arguments to this call rather than in one long string. Also there may be options on how your child process is launched, so waiting for it to return may be optional and so forth.
We use Perl script to launch a trace32 window on a remote machine and perform some operation, obviously the Perl cannot print any logs from trace32 window as its a separate GUI, very rarely the script fails probably because the trace32 failed, but there is no way to check in Perl script log about the trace32 failure, is there a command line option available to fetch the status or the error message printed in trace32 window ? thanks.
Maybe it is too late now, but for others looking for the same answer, what I did was save the B::area window log into a file and regex that file to my heart's content.
Here's a sample command to do it:
Prt.file C:\some\path\log.txt
winprint.area A000
prt.file
This can be done to any window area, by default the B::area window name is A000 that i know of.
Area.View is the command to view the status messages and various operations performed during debugging on trace32. When the command is run, trace32 displays an window named "B::area.view".The contents of window can be saved to a text file and later parsed to check the error using perl. Hope this hepls.
The default location for printing error or status messages is the AREA window with the ID "A000".
TRACE32 has commands for logging its contents to a file:
AREA.OPEN A000 protocol.lst ; area will be saved in 'protocol.lst'
DO test
...
AREA.CLOSE A000 ; all messages will be saved
AREA.OPEN <id_area> <file> opens a file for logging and directs all messages to be printed in the selected AREA window to it.
AREA.CLOSE <id_area> stops the logging.
Please refer to the file ide_ref.pdf for a detailed description of these commands.
I'm trying to make a small program that could intercept the open process of a file.
The purpose is when an user double-click on a file in a given folder, windows would inform to the software, then it process that petition and return windows the data of the file.
Maybe there would be another solution like monitoring Open messages and force Windows to wait while the program prepare the contents of the file.
One application of this concept, could be to manage desencryption of a file in a transparent way to the user.
In this context, the encrypted file would be on the disk and when the user open it ( with double-click on it or with some application such as notepad ), the background process would intercept that open event, desencrypt the file and give the contents of that file to the asking application.
It's a little bit strange concept, it could be like "Man In The Middle" network concept, but with files instead of network packets.
Thanks for reading.
The best way to do it to cover all cases of opening from any program would be via a file system filter driver. This may be too complex for your needs though.
You can use the trick that Process Explorer uses to replace itself with task manager. Basically create a key like this:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\taskmgr.exe
Where you replace 'taskmgr.exe' with the name of the process to intercept. Then add a string value called 'Debugger' that has the path to your executable. E.g:
Debugger -> "C:\windows\system32\notepad.exe"
Every a process is run that matches the image name your process will actually be called as a debugger for that process with the path to the actual process as an argument.
You could use code injection and API redirection. You'd start your target process and then inject a DLL which hooks the windows API functions that you want to intercept. You then get called when the target process thinks it's calling OpenFile() or whatever and you can do what you like before passing the call on to the real API.
Google for "IAT hooking".
Windows has an option to encrypt files on the disk (file->properties->advanced->encrypt) and this option is completely transparent to the applications.
Maybe to encrypt decrypt file portions of a disk you should consider softwares like criptainer?
There is this software as well http://www.truecrypt.org/downloads (free and open source) but I haven't tried it.
Developing a custom solution sounds very difficult.