http://forums.leaflabs.com/topic.php?id=2015 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:09:43 +0000 http://bbpress.org/?v=1.0.2 q http://forums.leaflabs.com/search.php http://forums.leaflabs.com/topic.php?id=2015#post-11609 Fri, 06 Jul 2012 10:09:35 +0000 JoshSanders 11609@http://forums.leaflabs.com/ <p>Yes, the board's main loop continues to operate - I modified the sketch above to include a few lines that blink the LED. When I send a 64-byte packet, the software crashes on the computer end, but the LED keeps blinking.</p> <p>I don't generally split the message in two because I often send large messages (up to 4000 bytes). So long as the entire message length isn't a multiple of 64, this works fine (presumably sending many 64 byte packets in the process). In terms of USB2.0, the hangup seems to be if the last packet in the message is full...</p> <p>Thanks for your feedback! I'm less of a USB expert than I'd like to be... </p> http://forums.leaflabs.com/topic.php?id=2015#post-11547 Wed, 04 Jul 2012 14:41:33 +0000 mbolivar 11547@http://forums.leaflabs.com/ <p>Hi Josh,</p> <p>Thanks for the report. Glad you've got a workaround for now. Instead of chopping off bytes, however, why not just split the message in two, where neither part has a size divisible by 64?</p> <p>Also, just to be clear, does the board continue to work correctly after sending such a packet, even if the computer freaks out?</p> <p>gbulmer, you're correct that 64 bytes is the max packet size for USB 2.0, and we do set bMaxPacketSize to that value. So this is a suspicious happenstance, to say the least. It's odd that 65 bytes works correctly, however, since in principle you'd expect that to be sent as a 64 byte packet followed by a 1 byte packet. </p> http://forums.leaflabs.com/topic.php?id=2015#post-11527 Tue, 03 Jul 2012 19:16:55 +0000 gbulmer 11527@http://forums.leaflabs.com/ <p>Interesting - IIRC USB packets are 64 bytes. </p> http://forums.leaflabs.com/topic.php?id=2015#post-11525 Tue, 03 Jul 2012 18:49:49 +0000 JoshSanders 11525@http://forums.leaflabs.com/ <p>Hi guys!<br /> I have run into a bug affecting both Maple r5 and Maple Mini r2, that I was hoping I could get some help with.<br /> In 32-bit Windows XP SP3 (but not Windows 7), sending specifically 64 byte (or multiple thereof) messages over the serial terminal results in a crash of whatever software was talking to Maple.</p> <p>An example using Maple's IDE:<br /> Load the following sketch -</p> <p>int inByte = 0;</p> <p>void setup() {<br /> }</p> <p>void loop() {<br /> if (SerialUSB.available() &gt; 0) {<br /> inByte = SerialUSB.read();<br /> }<br /> }</p> <p>In Windows XP SP3 32bit, do the following: </p> <p>Step 1: open the Serial terminal in the IDE and send a string of A's, like this string of 63 A's:<br /> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA<br /> or this string of 65 A's:<br /> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA<br /> Step 2: Send any other message (for instance, AAA)</p> <p>So far so good.<br /> Now, try the following:</p> <p>Step 1: open the Serial terminal in the IDE and send a string of 64 A's<br /> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA</p> <p>Step 2: Send any other message (for instance, AAA)</p> <p>The IDE should now be frozen, and you'll have to quit the process from the task manager.</p> <p>I originally ran into this problem when sending messages of arbitrary lengths from the MATLAB serial terminal, and subsequently tested the bug on several WINXP and WIN7 computers with different configurations. WIN7 doesn't seem to have a problem here. Is this a driver issue? Or perhaps some quirk with XP's default configuration of the serial port? I'd have guessed a buffer overflow but it's specifically a problem with messages that are multiples of 64 bytes in length...</p> <p>Anyhow, if you guys have any guidance, please let me know! I'd rather not work on XP at all, but I'm developing a system that has to be robust across platforms.<br /> For now I'll try to code around the issue by checking the message size, adding an extra byte if length is a multiple of 64, and chopping it off on the other end.</p> <p>Cheers,<br /> Josh </p>