I am working on Lauterbach to collect the traces from a sink where a processor is a source.
This is done using a 'step' operation and while doing so, in the midway on the trace.list window I am displayed with 'TRACE ENABLE' in red (as attached in the image).
My question is, what does this mean? what does the TRACE ENABLE indicate?
Any help would be appreciated, thank you.
Related
I'm more of a HW engineer who's currently trying to use Python at work. What I want to accomplish via Python is read the CAN-FD output from the DUT and use it for monitoring purposes in the measurement setup. But, I think I didn't get the correct result. Because it shows the same message(id) even there so much more. Based on my understanding from other examples, this should shows the stream of all the messages since there was no filters. Is there anyone who can help me solve this issue or have the similar experience?
import can
def _get_message(msg):
return msg
bus = can.interface.Bus(bustype='vector',app_name ='app', channel=1, bitrate=500000)
buffer = can.BufferedReader()
can.Notifier(bus,[_get_message,buffer])
while True:
msgs = bus.recv(None)
print(msgs)
You don't say what you expected to see on your bus, but I assume there are a lot of different messages on it.
Simplify your problem to start with - set up a bus which has only a single message on it at a low rate. You might have to write some code for that, or you might get some tools which can send periodic messages with counters in for example. Make sure you can capture that correctly first. Then add a second message at a faster rate.
You will proably learn a selection of useful things from these exercises which mean that when you go back to your full-system you have more success, or at least have more ideas on what to debug :)
First of all, thanks for the answers and comments. the root cause was the incorrect HW configuration for the interface. I thought if HW configuration is wrong in the first place, there will be no output at all. But it turned out it is not. After proper configuration, I could see the output stream I expected.
We have a customized i.MX6Q Board based on sabrelite reference board.
We have the following configuration:
Linux : 3.10.53
Gstreamer 1.0 latest i.MX6 Plugins
We connected OV5642 Camera over CSI Interface..Used the following command to display the camera output on the screen.
gst-launch-1.0 imxv4l2videosrc device=/dev/video0 imx-capture-mode=4 fps-n=15 ! imxipuvideosink
It works, but initially, it takes time to settle for few seconds, there is genlock issue
But when I modify the fps to 30, I get distorted output.. What do you think is wrong here.. Any help is appreciated...
Could be related to imxv4l2videosrc. Obviously you also guessed it since you also posted the same question on GitHub. Setting the environment variable GST_DEBUG=3 could give you more information. 3 means FIXME, so you would see if this is a problem some developer is already aware of. See Running GStreamer Applications for more information on GST_DEBUG.
I'm trying to set up my LabView VI + my USB 6001 I/O box to be able to read multiple independent voltages at once, while also outputting a single constant voltage.
I've successfully gotten my USB box to output the voltage I want while reading back a single voltage, but so far I've been unable to read back more than one voltage (and if I do, the two voltages seem to be co-dependent on one another in some way).
Here's a screenshot of my VI:
Everything to the right of the screenshot window should be unimportant to the question.
If anyone is curious, this is to drive multiple LVDT's and read back their respective voltages.
Thank you all for your help!
Look at your DAQ's manual, especially the pages I noted below.
http://www.ni.com/pdf/manuals/374259a.pdf
Page 11
All the AI channels get multiplexed, and the low-side reference can be switched (RSE vs. differential). So the two channels you're sampling require both of those to switch. It might be a settling issue where the ADC is taking a sample before the input value is stable.
To verify this, try using using the same low side (differential or RSE) on both channels. Also try slowing down your sample rate (but your 1 kHz should already be slow enough...).
Page 14
Check this to make sure you have everything connected and grounded correctly.
Page 18
Check this for more details about switching between 2 sources quickly.
Perhaps you could try it using the Daqmx express VIs:
http://www.ni.com/tutorial/2744/en/
Does anyone know how to reset an Advanced Card Systems NFC reader type ACR1255U-J1? I've sent an escape command to it and it got stuck. When I switch the button at the top I get a purple light for LED1 and orange light for LED2 followed by red light for LED1 and no light for LED2. Any help will be appriciated.
I can see the device through Mac Terminal when it is connected through USB but it is no longer visible when bluetooth is on.
Once the ACS1255U-J1 shows the behavior you described it's basically bricked. It happens because of a stack overflow problem (no pun intended) in the readers' firmware and ACS is currently working to correct it. I've seen it happen repeatedly with very long Escape Commands like the Rewrite Master Key Command Request (36 bytes long) as well as some shorter ones. Depending on the severity of the overflow, you may be able to resurrect the reader by reflashing it with fresh firmware. You can download all the stuff you need from our site here:
http://flomio.com/ACR1255U-J1-FlashTool/
You'll need a Win7 machine to work the tool and even then it'll take a few tries to get the reader in DFU mode. If you run into issues, post support questions on our forums and we'll be happy to help.
That said your device corruption may be beyond repair. This can happen if you've wiped out the boot sector of the flash. You'll know this if the reader fails to enter DFU mode. I've been able to resurrect a few readers but found them lacking some key setting like the serial number field being gone (all zeros). But more just don't enter DFU. We're authorized distributors of ACS products so if you want to RMA your device through us let me know and we can work something out.
UPDATE: Flomio now has the ability to repair bricked ACR1255U-J1 units. You can ping us on our forums for details.
It seems that "!htrace -diff" can only show 16 frames. How can I increase the frame counts in the stack traces? The following is one of the handles leaked detected by !htrace -diff. I can't read anything from it without a complete stack trace.
Handle = 0x00000f7c - OPEN
Thread ID = 0x00001cc4, Process ID = 0x00009f20
0x01b8dad8: +0x01b8dad8
0x018c6e93: +0x018c6e93
0x7788179a: +0x7788179a
0x000a20bb: +0x000a20bb
0x753ab069: +0x753ab069
0x7539cf87: +0x7539cf87
0x75322776: +0x75322776
0x7539d07e: +0x7539d07e
0x7539c549: +0x7539c549
0x778ae707: +0x778ae707
0x7785c32e: +0x7785c32e
0x77a2ff66: ntdll!ZwCreateEvent+0x00000012
0x69bffc58: verifier!AVrfpNtCreateEvent+0x0000006b
0x77390d93: KERNELBASE!CreateEventExW+0x0000006e
0x773911c6: KERNELBASE!CreateEventW+0x00000027
0x69bffd8f: verifier!AVrfpCreateEventW+0x00000078
This link point to this one Which tells that basically it is hard coded.
The maximum depth of the stack trace is currently hardcoded to 16
(although it's possible it will change in the future). Also, that
includes a few entries for the kernel-mode portion of the stack
trace. Those stack trace entries can be displayed by kernel or driver
developers by using !htrace in a kernel debugger. So getting around
11 user-mode entries for each of your traces sounds accurate.
Unfortunately you can't.
Assuming that you have symbols set up correctly, I see the following possibility
Some of the traces reported by !htrace may be from a different process context. In this case, the return addresses may not resolve properly in the current process context, or may resolve to the wrong symbols.
Source: WinDbg help (.hh !htrace)
This can happen if a different process injects handles into your process and the addresses correlate to that process. In this case, the process ID listed by !htrace does not match the process you're debugging (type | (pipe) to get the process ID).
In such a case, you can attach to the process (.attach 0x<pid>, 0n is default here) and try to get the remaining callstack from there, but I never did this myself.