Created Mon, 24 Mar 2014 17:43:16 +0000 by Bumbolt
Mon, 24 Mar 2014 17:43:16 +0000
I'm using Linux (Ubuntu 12.04) and a ChipKit Uno32. When i try to load my program onto the board i get the following output:
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_getsync(): timeout communicating with programmer
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
The power led is on and i got a pulse on LD1.
I tried both 32 and 64bit client. I uninstalled the braille usb driver.
The output of
dmesg | tail
after plugging in the board:
$ dmesg | tail
[19787.585898] usb 1-1.1: Product: FT232R USB UART
[19787.585903] usb 1-1.1: Manufacturer: FTDI
[19787.585907] usb 1-1.1: SerialNumber: A1009SE4
[19787.588721] ftdi_sio 1-1.1:1.0: FTDI USB Serial Device converter detected
[19787.588802] usb 1-1.1: Detected FT232RL
[19787.588811] usb 1-1.1: Number of endpoints 2
[19787.588819] usb 1-1.1: Endpoint 1 MaxPacketSize 64
[19787.588826] usb 1-1.1: Endpoint 2 MaxPacketSize 64
[19787.588833] usb 1-1.1: Setting MaxPacketSize 64
[19787.589375] usb 1-1.1: FTDI USB Serial Device converter now attached to ttyUSB0
In the IDE i did select the right board and serial port (running with sudo rights for this) I also used the example bliink code to make sure it wasn't code-related.
Google isn't my friend for this problem (ran out of posts, many people with the same problem on arduino mega but no solutions).
NOTE: The board was bought about a year ago, used it for a project (worked correct) and now i reinstalled the software and it gives me this.
Mon, 24 Mar 2014 17:48:18 +0000
Do you have any shields connected to the board?
ModemManager can sometimes cause problems with these kind of boards. It's recommended you disable or uninstall it.
Mon, 24 Mar 2014 18:05:11 +0000
I currently have no shield on the board. I did have one last year (dfrobot relay shield) but i did not have any additional firmware for that. The firmware should be the one from the factory.
I did have a couple Maxbotix Maxsonars conneced but the above output is tested without the sensors connected since that was my first concern too.
I also doublechecked the position of the jumpers and they are in the default position (cfr the datasheet)
With modemmanager you mean the bluetooth? Bluetooth is disabled. I only have an external usb hub with kb and mouse connected. The package "modemmanager" is not installed on my system.
Whilst scrolling into the output of the ide on startup i found:
Native lib Version = RXTX-2.2pre2
Java lib Version = RXTX-2.1-7
WARNING: RXTX Version mismatch
Jar version = RXTX-2.1-7
native lib Version = RXTX-2.2pre2
Not completely sure how to fix it yet.
Mon, 24 Mar 2014 18:16:29 +0000
By the symptoms you're describing it sounds like the board reset isn't triggering. Try pressing the reset button just as the upload is about to start (just as avrdude is about to execute).
Mon, 24 Mar 2014 18:24:53 +0000
I tried both holding the reset button down during the upload and just spamming it.
I get a different error than "not responding"
avrdude: stk500v2_getsync(): timeout communicating with programmer
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
I guess that's because i reset (cancel) the upoad with bad timing?
On the mismatch error: I seems weird because the version of rxtx-java, i have installed is more recent... (all the similar threads online have the problem that they are using an older version)
Mon, 24 Mar 2014 18:25:40 +0000
Whilst scrolling into the output of the ide on startup i found:
Native lib Version = RXTX-2.2pre2
Java lib Version = RXTX-2.1-7
WARNING: RXTX Version mismatch
Jar version = RXTX-2.1-7
native lib Version = RXTX-2.2pre2
Not completely sure how to fix it yet.
That is normal - you can ignore it. It's just a version mismatch between the java code for RXTX and the Linux shared (.so) library. It doesn't cause any known problems, and certainly not this one. Everyone on Linux has the same warning message.
Mon, 24 Mar 2014 18:26:53 +0000
I tried both holding the reset button down during the upload and just spamming it. I get a different error than "not responding"
avrdude: stk500v2_getsync(): timeout communicating with programmer
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
I guess that's because i reset (cancel) the upoad with bad timing?
You need just one brief tap of the reset button, and it has to be at just the right moment - just as the percentage bar jumps up to something like 75% full.
Mon, 24 Mar 2014 18:28:18 +0000
I'm glad that's ok.
I'll try some different reset triggering methods.
This is the progressbar when he starts to timeout.
Pressing earlier, or right after the "jump" of the compiler completing. No succes so far the only difference i see is that i get more timeouts (faster then when i do nothing)
What does this error exactly mean? He has connection, tries to send packets but the board doesn't answer (or not as expected)?
Mon, 24 Mar 2014 18:46:29 +0000
That's basically it, yes. The software is sending packets, but the main MCU (PIC32) isn't responding (or the responses aren't getting through).
Possible causes include:
As the reset trick doesn't seem to be working it's most likely option 4. That may be either because the chip itself isn't running right (it's broken) or the bootloader code has become corrupted. If the latter it's possible to replace the bootloader code if you have a PIC hardware programmer available (pickit2, pickit3, ICD, chipKIT PGM, etc).
Mon, 24 Mar 2014 18:48:38 +0000
After having it let run for a while, whilst searching google. I pressed reset for about 1 second. After that i got this error:
avrdude: stk500v2_getsync(): timeout communicating with programmer
avrdude: stk500v2_command(): failed miserably to execute command 0x11
avrdude: stk500v2_disable(): failed to leave programming mode
After this error the progressbar completed and i got the message "done uploading" in the ide.
I can't repeat the trick..
I have no problem with the idea of flashing the bootloader. But since a programmer kit costs me as much as the board itself i think i'll just order a new board. (or 2 just in case)
Mon, 24 Mar 2014 18:52:20 +0000
It is also possible that you may have some avrdude executables lingering around that are corrupting the communications.
Try, from a terminal, running
$ sudo killall -9 avrdude
and retrying the upload.
Mon, 24 Mar 2014 18:59:21 +0000
No processes found after closing mpide.
Still getting timeouts when i open mpide and go straight to uploading the sketch (after killing all avrdude processes)
The LD1 led goes in a pulse. 4 second off. 2 fast blinks. 4 seconds off ... (not sure if relevant). And the blinking is synced with the terminal giving a timeout error.
Mon, 24 Mar 2014 19:03:32 +0000
Short digital pins 0 and 1 together, then use a terminal emulator (like minicom for instance) to try communicating - it should loop back and you'll see what you type. That will confirm that you are communicating OK with the board itself and the FT232 chip is functioning right.
Mon, 24 Mar 2014 19:06:56 +0000
I'll try that.
In the mean while (not sure when they appeared) some output:
avrdude: stk500v2_command(): unknown status 0x04
avrdude: stk500v2_cmd(): failed to send command
avrdude: stk500v2_command(): unknown status 0x04
avrdude: stk500v2_cmd(): failed to send command
avrdude: stk500v2_command(): unknown status 0x04
avrdude: stk500v2_cmd(): failed to send command
avrdude: Yikes! Invalid device signature.
Double check connections and try again, or use -F to override
this check.
avrdude: stk500v2_command(): unknown status 0x01
avrdude: stk500v2_disable(): failed to leave programming mode
I used minicom while pin 0->rx and pin 1<-tx were shorted. (i ran sudo minicom -s
to change to \dev\ttyUSB0 (as i figured out from dmesg
)).
I did not get an echo.
Since i'm on ubutunu is shouldn't need an extra driver right?
So that gets me to the ftdi chip on the board not responding.
UPDATE: for a more noobproof approach i tested on windows with pin 0 and 1 shorted. And connected using Putty. I did get an echo on there. On windows using the mpide i tried to upload the blink sketch but this did not upload. It keeps hanging around 98% of the progressbar just like on linux. But it doesn't give any errors and does not complete...
So this makes me think the FTDI chip on the board is ok. And i'm just clumsy in using minicom...
Since the pic chip isn't hot at all i think it's just not running (it has been plugged in for about 4 hours now...)
UPDATE2: I was able to connect through putty and get an echo of the typed chars by shorting 1 and 0, to. So the serial chip seems fine...
So if i check the list you shared earlier.. this means i have a corrupt bootloader or broken hardware?
Mon, 31 Mar 2014 19:19:22 +0000
When I have seen this problem on Ubuntu 10.10, I've found that my Mpide Serial Device assignment(/dev/usb0) is out of sync with Ubuntu's USB device initialization(/dev/usb1). Not sure why this happens....not a linux guru.
Try checking your syslog after you plug in the usb cable and see what device Ubuntu has chosen for you this time. Seems to change when you unplug and replug the usb cable. I just reset the Serial Device assignment as need be.
James
Mon, 31 Mar 2014 19:49:06 +0000
When I have seen this problem on Ubuntu 10.10, I've found that my Mpide Serial Device assignment(/dev/usb0) is out of sync with Ubuntu's USB device initialization(/dev/usb1). Not sure why this happens....not a linux guru. Try checking your syslog after you plug in the usb cable and see what device Ubuntu has chosen for you this time. Seems to change when you unplug and replug the usb cable. I just reset the Serial Device assignment as need be. James
If you unplug a USB serial device while said device is open (by the serial monitor, avrdude, whatever) the device entry remains locked - i.e., it still exists and isn't removed as it's still in use. When you then plug the device back in it obviously can't re-use the old device name, as it's already there and in use, so it picks the next available device number.
If you want to force a specific device name you can use a udev rule to match the device and create a symlink. I do that with one of my devices (the microcontroller that controls my workbench) so it's always available on the same name regardless of which devices on the USB bus get identified first:
[/etc/udev/rules.d/50-manlab.rules]
SUBSYSTEMS=="usb", ATTRS{product}=="Manlab", SYMLINK+="manlab"
There's lots of ATTRS you can use, including the VID and PID of the device, the name of it, manufacturer, serial number - you name it, most things are there to pick from.
The device is usually on /dev/ttyACM0, but could be /dev/ttyACM1, /dev/ttyACM2, etc, but with that rule it will also always be available on /dev/manlab which makes interfacing with it in software so much easier...
UPDATE2: I was able to connect through putty and get an echo of the typed chars by shorting 1 and 0, to. So the serial chip seems fine... So if i check the list you shared earlier.. this means i have a corrupt bootloader or broken hardware?
It's certainly looking that way, yes. You're able to communicate with the board, but the PIC32 isn't responding. From here on you'll need some proper diagnostic tools, things like an oscilloscope and a hardware PIC programmer, like a PicKIT3, or a chipKIT PGM for example.
If you have an oscilloscope you can try seeing if the oscillator is oscillating (don't forget to set the probe to x10 mode or your probing may stop the oscillations).
If you have a hardware programmer (or a friend with one) you can try seeing if the chip is detected using MPLAB-X IPE. If you have a PicKIT2 especially, then you can use the program "pic32prog" available on google code (written by my friend Serge) which is great for diagnostics with a pickit2 as it can identify the chip and return all the config settings with just one command - very useful.
Wed, 02 Apr 2014 18:26:42 +0000
Majenko:
Thanks for the explanation of the USB port assignment under Linux.
I'm sure I was/am leaving the serial monitor open.
I have seen the udev stuff before. Not an everyday user, but was able to use similar commands to get a Kodak multi-function printer to work under CUPS/SANE.
James