I am trying to use Clion IDE to debug various NXP ARM M MCUs using J-link.
In case when program is only in RAM it works fine but but in case of flash targets after program load IDE often slows down for a while and then I will get timeout. Some click on pause button in right moment pauses program somewhere and allows me to debug...
My question is there any way how to see interactions of IDE with armgdb client or armgdb and j-link gdb server?
I tried to capture communication with gdb server using wire shark but it seems to be a binary protocol...
Thank you.
I found there is possibility to let gdb echo commands which showed me what is going on.
Unfortunately in case of Clion the only way is to put it into .gdbinit file in the root of project.
set trace-commands on
It showed me warning
warning: A handler for the OS ABI "Windows" is not built into this configuration
of GDB.
Which leads me to comment of this question gdb-multiarch (MINGW64) cannot determine architecture from executable?
Well I am not sure what caused Clion to hang but having .gdbinit with just set osabi none in it solved it.
I am trying to run Gem5 system emulation with a binary I compiled from a Golang program. I am using X86 O3CPU and classic memory. However, I have to launch the same process on 3 cpus to have the system emulation set up. Otherwise I will receive error: fail to create new OS thread. I try to set the GOMAXPROCS to 1 or MAXTHREADS to 1. Neither of them solve this problem.
But even if i run the binary with 3 cpu. I still might receive error:
wirep: p->m=824633877504(2) p->status=1
fatal error: wirep: invalid p state
after many hours of emulation. Does anyone have experience with running Gem5 with Golang?
I have a c++ program running "fine" but when I try to debug it with LLDB, LLDB just quits on me.
Process ... launching
Segmentation fault
Even if I set a breakpoint on the very first line in main I just get these two lines. Googling yields the typical memory leak errors in user code. I don't think that's the case here since my program runs outside of LLDB.
I am not experiencing any issues under ubuntu. Could it be related to ARM (raspberry pi)?
You might have more luck sending a query about the state of the lldb port to raspberry pi on the lldb-dev mailing list. Details here:
http://lists.llvm.org/mailman/listinfo/lldb-dev
I made a node which contains a USRP_UHD and a GPP (and make sure the ip_address is correct for USRP_UHD). I launched the domain based on this node. However, I got the following error:
UHD Error:
Device discovery error: AssertionError: libusb_init(&_context) == 0
in libusb_session_impl::libusb_session_impl()
at /builddir/build/BUILD/uhd-release_003_005_003/host/lib/transport/libusb1_base.cpp:37
UHD Error:
Device discovery error: AssertionError: libusb_init(&_context) == 0
in libusb_session_impl::libusb_session_impl()
at /builddir/build/BUILD/uhd-release_003_005_003/host/lib/transport/libusb1_base.cpp:37
...
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
UHD Warning:
Unable to set the thread priority. Performance may be negatively affected.
Please see the general application notes in the manual for instructions.
EnvironmentError: OSError: error in pthread_setschedparam
I did get two unallocated (TX/RX for each) tuners, but it is not easy to allocate these two tuners for use for any parameters.
Besides, if I just launch the domain and launch the single device USRP_UHD, or simply run the discover USRP_UHD command via the command line window, I got the same error:
UHD Error:
Device discovery error: AssertionError: libusb_init(&_context) == 0
in libusb_session_impl::libusb_session_impl()
at /builddir/build/BUILD/uhd-release_003_005_003/host/lib/transport/libusb1_base.cpp:37
2016-02-01 16:59:20 WARN USRP_UHD_i:943 - WARNING: NO UHD (USRP) DEVICES FOUND!
Could anybody figure out where this problem is? Thanks in advance!
So, first of all, the good news is that this is happening during autodetection of USB devices, so your N2xx is not inherently affected, but:
UHD 3.5.3 is not only old, it's ancient. You should really uninstall it (If you've got Debian or a derived one [Ubuntu], it'd be sudo apt-get remove uhd-host libuhd003 libuhd-dev), install a new version directly from Ettus (can help you with that, if necessary) and rebuild Redhawk against that version.
Really, really do that. There's been so much improvement in behaviour like failure handling that fixing this without updating isn't really worth it.
Now, if you explicitly specify a device address that allows you to cancel USB-based USRP detection completely, you should be fine. As device address, use type=usrp2 for USRP2, N200 and N210.
I ran into this issue trying to install UHD v3.9.3 in a CentOS 7 Docker container - the error message points to a usb issue, not related to Redhawk. The Redhawk Device, USRP_UHD, is just an abstraction layer on top of the Ettus UHD drivers, so the easiest way to tell whether the problem is Redhawk or something else is to try one of the UHD commands directly from a terminal to generate the same error, like uhd_usrp_probe.
To check if the problem is directly related to the usb drivers try the command lsusb. This should list all usb devices connected to your OS. These are good debug tips to isolate where the problem is.
If you happen to be doing this using Linux containers or Docker you have to give the proper privileges, see docker-any-way-to-give-access-to-host-usb-or-serial-device. Otherwise, assuming you built UHD from source, check the output of make test step - if all the tests passed there shouldn't be anything wrong with the UHD library.
Edit: Also if you're running this inside a VM you have to make sure your host has given network/USB/etc privileges to the hypervisor (ex. VirtualBox) during installation, or that you've attached the correct virtual hardware in the VM configuration.
I am trying to fix some error related to a SEGMENTATION FAULT. So when I try to fix the error using by step by step debugging of the code, I got couple of errors:
ERROR: cuda_trace_obj::initialize_cuda_library: Cuda initialize() returned CUDBG_ERROR_INITIALIZATION_FAILURE(20)!
ERROR: cuda_system_status_t::initialize: Error CUDBG_ERROR_UNINITIALIZED(5) getting device count
Any help or pointers regarding the above mentioned errors is appreciated.
This error often occurs when you debug a CUDA application on a computer with a single GPU and an X11 server running.
In a single GPU system, CUDA applications can be used debugged only if no X11 server (on Linux) or no Aqua desktop manager (on Mac OS X) is running on that system.
As far as I know, only the command line debugger CUDA-GDB is able to override this restriction setting software preemption as described in the cuda-gdb documentation, but works only for devices with SM3.5 compute capability and higher.