poslathian
LeafLabs
The root issue is also fixed, but it takes some hacking depending on your system.
On newer ubuntu dists (like karmic) just copying the udev rule should do the trick, and restart your udev (not sure if thats in the script...but sudo /etc/init.d/udev restart)
on debian and older dists, you need to create the group "plugdev" and add yourself to it, then do the above
$ sudo addgroup plugdev
$ sudo usermod -G plugdev your-user-name
let me know if that helped.
beckel
Member
Hi all, I have a myriad of problems here and I feel like they are mostly related to issues dealt with in this thread.
For starters, my environment is Ubuntu 9.10. I just got a Maple board and it had '27' written on the anti-static bag. I had tried this on windows but could not get it working. Also, I am using the openjdk and I am running the ide as root. Now onto the issues...
First off, when I first powered up the board, I don't think it ever ran the 'default user code'. It would go through the startup process, quick blinks then slow blinks, then the LED would just remain lit. I am assuming the default user code is some kind of blink program?? so this is some kind of mistake?? After trying to program to RAM, it now starts up and blinks at ~3-4 times a second. I am not sure if this is an assertion failure?? This started occurring the first time I got a successful restart from the ide. That is the real problem. I can't get my modified blink program onto the board...
I created my own copy of the blink sketch and changed the on and off values to 2000 and 500 for an obvious visual uniqueness, then i set the board to write to RAM, then I set the serial port to ttyACM0. I attempted an upload. The code compiled fine and here is the end of the message:
............
Binary sketch size is reported above. Check it against a 17000 byte maximum)
Loading via dfu-util
Resetting to bootloader via DTR pulse
Error inside Serial.serialEvent()
java.io.IOException: Input/output error in nativeavailable
at gnu.io.RXTXPort.nativeavailable(Native Method)..........
The rest of this Java stack trace appears to be similar to coreyfro's. Mine also ends with the same "No DFU device found" message. Trying again at this point results in this message:
Binary sketch size is reported above. Check it against a 17000 byte maximum)
Loading via dfu-util
Resetting to bootloader via DTR pulse
Reset via USB Serial Failed! Did you select the serial right serial port? Or perhaps youre in perpetual bootload mode, continuing to attempt dfu programming anyway...
No DFU capable USB device found
dfu-util - (C) 2007 by OpenMoko Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY
At this point I checked the Tools->Serial Port option and now I have an unchecked ttyACM1. It appears that everytime the board resets it switches ports and that number is increased.
I tried fiddling with the Delay After Reset field as suggested but that didn't get me anywhere. Any help would be greatly appreciated. I can provide more info if needed.
poslathian
LeafLabs
I think what is happening is that the stack dump from the gnu io error is mucking up the timing synchronization between reset and upload. Based on your description, your board sounds OK. The "default user code" is a test program that dumps a bunch of info over serial, not blinky.
Asserts are indicated by a fading LED, not blinking, so youre ok there.
The ACM number incrementing is caused when the serial device (maple running user code) detaches while some program (such as the serial monitor, or minicom, or screen...or anything) still has the device open. Its likely that that the big bag of stack trash from gnu.io is related to the serial port not closing and thus related with the ACM number incrementing.
For now (until we push a better fix in 0.0.4) you can use perpetual bootloader mode. To enter this mode, hit reset, then immediately after (during the quick blinks) hold down the boot button on the side labelled BUT. Continue to hold it until the longer blinks start. Now try uploading (you wont have a serial port in this mode, but after uploading code you should have it again).
Sorry about this issue, its essentially one of "tuning" the delays, which is a nasty solution, were working on something more robust. Based on results on the local machines we thought we had pretty wide margins to play in, but apparently they were narrower than we thought.
The effect is also totally non deterministic. On my machine, I get successful uploads to RAM and FLASH with a programDelay of 1000 about 5/6 times.
beckel
Member
Just for the record, this was resolved. I went through some debugging with postlathian in IRC. I just had a hell of a time getting into perpetual bootloader mode but once I did I was able to upload code. The button pressing sequence is very finnicky.
Another thing we learned is that using a VM complicates the process. I was using an Ubuntu VM on an OS X machine. It 'seems to' take longer than normal to re-enumerate so for right now I am probably going to modify the bootloader to default to perpetual mode. Also, make sure your USB device passthroughs are working properly if your dfu-util cant't find the device.
poslathian
LeafLabs
Thanks beckel for posting. Its worth noting that virtualBox is worse that vmware on this issue. It takes virtualBox an awful lot of setup to get the device filters working for permanent device passthrough and the device enumeration/driver loading process takes long enough that the bootloader is often gone by the time the drivers get loaded. In vmware, you can usually get up and running just by setting the programDelay on the high side, say 1200 or so.
If anyone get things working on virtualBox, wed love to hear about it!
You must log in to post.