I have simulated CHSTONE benchmark by Gem5 simulator and got a trace file with it. after that I need to simulate this trace file in OMNET++ and get the result.
How can I do this and how can I use this file as an input in OMNET++?
Related
I want to run a Simulink model in real time. So I need the Real time sync block in "Simulink desktop real time" (sldrt) toolbox working. It seems to be correctly installed, also in path. But I always get the error:
Error in S-function 'real_time_test/Real-Time Synchronization': Unable to acquire handle to MATLAB function 'sldrtsync'
Component:Simulink | Category:Blockerror
This error occurs also with the Desktop real time example _sldrtex_vdp_ also see my minimal example that I cannot get working..
In the sldrt directory there are two files:
sldrtsync.mexw64
sldrtsync.tlc
This path is also included in Matlab Path.
API: Win7 64bit
Matlab R2016b
Windows SDK 7.1
Where to look for the solution?
I am following this MathWorks File Exchange Link. I am having problem while running the myarduino_blink.slx demo.
My MATLAB version is R2015a, and I am using an Arduino Uno. I ran the file setup_custom_target_arduino.m after changing the relevant directory listing and the arduino version in the m file, and I got the output of Arduino on COM 3, which was correct.
After this, I checked the Simulink Library Browser and I had the Custom C/C++ Target Arduino Library will all its modules. Now when I simulate the model, I get the following error:
Error in S-function 'myarduino_blink/Digital Output':
S-Function 'sfunar_digitalOutput' does not exist
Kindly help me out, what could I have done wrong?
Update 1
Ok, I solved the "does not exist" problem. Apparently, no MEX compiler was installed. So I installed the Windows SDK, then re-ran the m file and now I am able to generate the .mex64 files. Now I run into another problem, when I build the simulink model, it gives this error:
Build procedure for model: 'myarduino_blink' aborted due to an error
How to solve this?
setup_custom_target_arduino.m calls build_all_sfunctions.m which should compile all of the S-Functions in the blocks directory. It looks as if that hasn't occurred for some reason. Check in the blocks directory that each of the S-Functions has a .c, .tlc (both of which come with the package) and a .mex64 (which is the compiled version of the .c generated by build_all_sfunctions.m) file.
If they are not there then the setup hasn't executed correctly, and you'll need to compile all of the S-Functions.
If they are there then you most likely have some sort of path issue (although since you say you can see the library in the library browser this seems unlikely).
I was debugging a new program, which was logging much output that was going by too fast to read. Suspended program to look at output; it was deep within the logging package, in a native output routine. Then repeatedly pressed F7 to find out where program was in my code. F7 caused debugger to return to Logger (Java) output routines. At some point the following message appeared:
'Debug Source Display' has encountered a problem. An internal error has occurred.
C:\Softwares\v4.2_sr2_juno_64bit\eclipse\configuration\org.eclipse.osgi\bundles\1193\1.cp\lib\linux\x86\libjd-eclipse.so: Can't load this .dll (machine code=0x101) on a AMD 64-bit platform
I have done this (F7) sequence hundreds of times before and not seen this error.
Installing JD-eclipse plugin solved this issue. below is the link for installing JD-Eclipse plugin
http://www.coolwebdeveloper.com/2013/04/how-to-add-jd-eclipse-plugin-java-decompiler-to-eclipse-juno/
I am using libsvm with Matlab R2011. My problem is that it has suddenly started to give me error about mex files and it won't run again.Interesting thing is the same program was running some time back but now its not working.
Error is as follows.
%%%%%%%%%%%%%%%%%%%%
Segmentation violation detected at Thu Mar 21 07:01:31 2013
.......then some stack trace files name....
This error was detected while a MEX-file was running. If the MEX-file
is not an official MathWorks function, please examine its source code
for errors. Please consult the External Interfaces Guide for information
on debugging MEX-files.
Caught MathWorks::System::FatalException
%%%%%%%%%%%%%%%%%%
can anybody help me on this?
Thanks.
There could be some error in your input data format. Since libsvm is open-source, you can try debugging your mex file using Visual Studio(in Windows) by attach-to-process. google "mex file debugging" for more detail
You maybe forget to delete some path ,you can check some paths you added before.After you added some paths,you must delete.If you do not do this,it will do not know what function to use.
I'm currently working on a project on STM32F4 and I'm using Eclipse. I've got some problems with the program - it seems to have a random behavior - sometimes it works fine, other times it has some errors. Sometimes when I try do debug with breakpoints I get the beautiful HardFault Handler and it really messes with my brains.
Sorry for the little off-topic paragraph, just wanted to let you know why I decided to use printing to a log file at some key moments in the program so I can see in which states and in which functions does the problem occur. I'm debugging through a JTAG interface with Eclipse (gdb) and I need to know if there is an easy method integrated in Eclipse that may help me use fprintf-like functions inside my program to write to a file on the disk.
If no, any other solutions?
Thanks
I do not like to connect the debug output log to the Jtag communication port because the log will not be available after development.
I usually build an SystemLog library that can send the log messages through any medium that is available (UART, USB, Ethernet or SDCARD). That's what I'd recommend you to do. It will help you through the development, and the support team on the event of any failure on field.
If stdlib is available in your project you should use the snprintf family functions to build your SystemLog.
Also, you can integrate the log output to the eclipse console by calling a serial console communicator (if you use UART) on you makefile, in this case, your makefile will have to flash the target as well.