I keep getting this error with ICD 3 when attempting self test:
Could not connect to the selected hardware tool. Please make sure the tool is not being used by another project in MPLAB X.
The device works fine under Ubuntu 12.04. Mplab can see the ICD3 device because it gets the correct serial number. lsusb reports the same values that Mplab reports as well. I tried running Mplab as root and that made no difference - this is not a permissions problem.
I tried this solution: https://www.microchip.com/forums/m1051283.aspx but it did not work. I also tried to close all projects so I had in the projects bar, and got the same error.
I tried the udevadm as suggested by this comment: https://www.microchip.com/forums/m1083236.aspx an it shows Mplab is trying to talk to the ICD 3:
$ udevadm monitor --property
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent
KERNEL[3219.382129] bind /devices/pci0000:00/0000:00:16.2/usb3/3-1/3-1:1.0 (usb)
ACTION=bind
DEVPATH=/devices/pci0000:00/0000:00:16.2/usb3/3-1/3-1:1.0
DEVTYPE=usb_interface
DRIVER=usbfs
INTERFACE=255/0/0
MODALIAS=usb:v04D8p9009d0100dcFFdsc00dp00icFFisc00ip00in00
PRODUCT=4d8/9009/100
SEQNUM=3378
SUBSYSTEM=usb
TYPE=255/0/0
UDEV [3219.387110] bind /devices/pci0000:00/0000:00:16.2/usb3/3-1/3-1:1.0 (usb)
ACTION=bind
DEVPATH=/devices/pci0000:00/0000:00:16.2/usb3/3-1/3-1:1.0
DEVTYPE=usb_interface
DRIVER=usbfs
ID_USB_CLASS_FROM_DATABASE=Vendor Specific Class
ID_VENDOR_FROM_DATABASE=Microchip Technology, Inc.
INTERFACE=255/0/0
MODALIAS=usb:v04D8p9009d0100dcFFdsc00dp00icFFisc00ip00in00
PRODUCT=4d8/9009/100
SEQNUM=3378
SUBSYSTEM=usb
TYPE=255/0/0
USEC_INITIALIZED=3219386787
A few seconds later it unbinds. So far I'm just hearing crickets on the Microchip forum. Anyone else tried using ICD 3 under Ubuntu 18?
Mike
After much head beating, I found that there were a lot of .jar files in the microchip mplab directory. But Java was not installed on my version of Ubuntu. After installing openjdk (and placing the correct device for loop back) I got MPLAB to talk to the ICD 3.
I am really surprised this was not obvious. If you have any MPLAB problems under Ubuntu 18.04, check if java is installed! (sudo apt install default-jre)
Related
I've installed (OSX Mojave 10.14.6.) Eclipse CDT and GNU MCU Eclipse plugin and finaly GNU Tools for ARM. My goal is to build and debug ARM code using GDB (arm-none-eabi-gdb).
I've created a Hello World project for Arm, which builds ok - but, debugging seems not to work with GDB (that comes with the Arm package). GDB gets stuck:
I have set the proper paths in Eclipse to arm-none-eabi-gdb.
I have signed the arm-none-eabi-gdb (with the same certificate that I used to sign GDB installed via brew into /usr/local/bin/gdb the day before - and it worked!).
I have also tried running Eclipse as root from command line.
Nothing helps.
The message is "Configuring GDB Aborting configuring GDB".
What to do?
Probably what is going on here is that you built to a given target (ARM based) and you're trying to run it (with gdb) on your mac (x86).
You'll need an emulator or QEMU to properly run on your mac or maybe a real board.
I recently downloaded the v3 of the FourQlib [1], build the FourQlib and wanted to test if everything went well.
First of all, my system:
Windows 10 (host) with MinGW, ARM Toolchain, MSYS, ...
Ubuntu 16.04 LTS (Guest) (gcc, arm toolchain, ...)
VirtualBox
STM32F429ZI-Disco
The source [1] includes the directory "FourQ_ARM", when compiling you have to start the "monitor.sh" [2] file in a terminal. Since they (Longa et al.) link to "ttyUSB0" I'll checked, if there is any device registered in Ubuntu. Since my µC ist registered as "stlinkv2_2 I changed this symbolic link "/dev/ttyUSB0 -> /dev/stlinkv2_2".
If I run the monitor.sh, the beginning will turn me in an error:
stty -F /dev/stlinkv2_2
leads to the error "Vorgang nicht zulässig" which means something like "Operation not allowed"
Could someone explain me, why I get this error and how to get this shell-script work?
[1] https://github.com/Microsoft/FourQlib
[2] https://github.com/Microsoft/FourQlib/blob/master/FourQ_ARM/tests_Cortex-M4/monitor.sh
The solution is: Using extra hardware with an old driver. Using TTL to USB-converter.
If someone needs to use the FourQlib on a STM32F407, use their USART and monitoring tools. On different processors you need to choose different USART pins. Those with a display connected allready use those pins.
Here is an issue I've worked around by simply not using Eclipse for debugging, but it's getting out-of-hand.
I've used Eclipse Helios, Juno and Kepler over the last year and they all display exactly the same problem when I try to debug a local C/C++ application.
When I try to debug, it simply reports the error "Error while launching gdb --version".
gdb is in my path, but to be sure, I change the Debug settings to list the path explicitly. If I do that, I simply get "Error while launching /usr/bin/gdb --version", which is no better.
I'm using Scientific Linux version 6.4 (as required by my customers) and currently, I'm trying to use Eclipse Kepler. Running from the command line, gdb has no problem reporting it's version:
# gdb --version
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6)
[... licensing info]
Please, please let me know how to fix this as I have spent weeks working at only a fraction of the rate I would expect because I'm not utilizing an integrated development environment, but using separate tools.
I've seen other similar posts, but they are either
(a) about Windows / MingW - although I've tried their ideas anyway, just in case they work.
(b) don't have any answer provided.
As Scientific Linux is a RedHat derivative, I expect RHEL or CentOS information would be as relevant for me.
I have a CC2538dk board. I am using Ubuntu 12.04 and cloned Contiki repository from github. I was able to compile all the code in Contiki using make TARGET=cc2538dk hello-world, but I'm not able to upload the code to the CC2538dk board from command line.
The error I'm getting when I ran make TARGET=cc2538dk hello-world.upload is as below.
make: No rule to make target `hello-world.upload'. Stop.
I used to use TI's Uniflash tool (CCS_Uniflash v2.2) to upload the the .elf binary, but it is not available in Contiki.
There is no make target for uploading to CC2538dk boards. According to the documentation one should use TI's UniFlash.
I had success compiling the contiki examples on a separate computer, then using Code Compose Studio v 5.4 to import my binaries (ELF files) to an empty CC2538 project, then debug it from there in order to get it loaded onto the board. Definitely not ideal, but it works.
Setup:
Compile contiki source and examples from instantContiki
move the example directory, included blink.elf to windows machine with CCS 5.4 installed
make a new project in CCS, select Other Examples->Empty CC2538 Project
Import a C/C++ executable, then using the GNU Elf reader, select the blink.elf file you moved over
copy+paste the CC2538SF53.ccxml and the cx2538xf53_ccs.cmd to the new project, and try to debug using those configurations.
The reason this seems to work is that the xds100v3 drivers that come with the board's install disc and the uniflash tool don't seem to work right and just give me any number of errors. There's a black-magic-configuration-combination of the CCS 5.4 for Window's drivers/Other Example's CC2538SF53.ccxml that was the only way I was able to connect to the target.
I am supposed to compile /usb/serial/ch341.c file to ch341.ko.
I am using rs485 module which is not working. I found on some forums that other people also facing this problem because drivers come with old device id in ch341.ko file and device comes with new device id -
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=82078234d4023c61b9d88e8be5e795423d17538e
I need to add new device id to ch341.c file which is alredy there in -
http://lxr.linux.no/linux/drivers/usb/serial/ch341.c
Now i need to compile this file to ch341.ko for raspbian wheezy to work in my raspberry pi.
Any help will be appreciated.
I had a CH341A (in SERIAL MODE) attached to my RasPI (raspbian wheezy with latest Upgrades).
To my surprise the CH341A SERIAL was recognized correctly and I communication
through "ttyUSB0" worked fine (using pySerial).
ls /dev/tty*
...look for "ttyUSB0" in the list.
You may want to follow the following blog posts:
Building modules for Raspberry Pi
More specific one on building a wireless driver
Following the steps outlined in these two posts you should be able to compile/ or cross compile your driver and get the required .ko file