http://forums.leaflabs.com/topic.php?id=37 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:10:26 +0000 http://bbpress.org/?v=1.0.2 q http://forums.leaflabs.com/search.php http://forums.leaflabs.com/topic.php?id=37&page=2#post-152 Mon, 31 May 2010 11:28:34 +0000 poslathian 152@http://forums.leaflabs.com/ <p>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. </p> <p>If anyone get things working on virtualBox, wed love to hear about it! </p> http://forums.leaflabs.com/topic.php?id=37&page=2#post-151 Mon, 31 May 2010 11:11:53 +0000 beckel 151@http://forums.leaflabs.com/ <p>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. </p> <p>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. </p> http://forums.leaflabs.com/topic.php?id=37&page=2#post-150 Sun, 30 May 2010 17:31:26 +0000 poslathian 150@http://forums.leaflabs.com/ <p>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. </p> <p>Asserts are indicated by a fading LED, not blinking, so youre ok there.<br /> 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. </p> <p>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). </p> <p>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. </p> <p>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. </p>