search

micronucleus / micronucleus

ATTiny usb bootloader with a strong emphasis on bootloader compactness.
Other
1.68k stars 384 forks source link

update.rb: error TRANSFER_STALL (LIBUSB::ERROR_PIPE) #35

Closed sodabrew closed 9 years ago

sodabrew commented 10 years ago

Not sure where to begin debugging this...

bundle exec ./upload.rb ../upgrade/releases/micronucleus-1.10-upgrade.hex
parsing input file as intel hex
Plug in programmable device now: (waiting)
Attached to device: <MicroBoot 1.2: 5.9 kb programmable>
Attempting to write supplied program in to device's memory
erasing
erased chip
uploading @ 0 of 6010
uploading @ 64 of 6010
uploading @ 128 of 6010
uploading @ 192 of 6010
uploading @ 256 of 6010
uploading @ 320 of 6010
uploading @ 384 of 6010
uploading @ 448 of 6010
uploading @ 512 of 6010
uploading @ 576 of 6010
uploading @ 640 of 6010
uploading @ 704 of 6010
uploading @ 768 of 6010
uploading @ 832 of 6010
uploading @ 896 of 6010
uploading @ 960 of 6010
uploading @ 1024 of 6010
uploading @ 1088 of 6010
uploading @ 1152 of 6010
uploading @ 1216 of 6010
uploading @ 1280 of 6010
uploading @ 1344 of 6010
uploading @ 1408 of 6010
uploading @ 1472 of 6010
uploading @ 1536 of 6010
uploading @ 1600 of 6010
uploading @ 1664 of 6010
uploading @ 1728 of 6010
uploading @ 1792 of 6010
uploading @ 1856 of 6010
uploading @ 1920 of 6010
uploading @ 1984 of 6010
uploading @ 2048 of 6010
uploading @ 2112 of 6010
uploading @ 2176 of 6010
uploading @ 2240 of 6010
uploading @ 2304 of 6010
uploading @ 2368 of 6010
uploading @ 2432 of 6010
uploading @ 2496 of 6010
uploading @ 2560 of 6010
uploading @ 2624 of 6010
uploading @ 2688 of 6010
uploading @ 2752 of 6010
micronucleus/ruby/vendor/bundle/ruby/2.0.0/gems/libusb-0.4.0/lib/libusb/dev_handle.rb:471:in `submit_transfer': error TRANSFER_STALL (LIBUSB::ERROR_PIPE)
  from micronucleus/ruby/vendor/bundle/ruby/2.0.0/gems/libusb-0.4.0/lib/libusb/dev_handle.rb:447:in `control_transfer'
  from micronucleus/ruby/micronucleus.rb:106:in `control_transfer'
  from micronucleus/ruby/micronucleus.rb:68:in `block in program='
  from micronucleus/ruby/micronucleus.rb:64:in `each'
  from micronucleus/ruby/micronucleus.rb:64:in `each_slice'
  from micronucleus/ruby/micronucleus.rb:64:in `program='
  from ./upload.rb:28:in `<main>'
sodabrew commented 10 years ago

My device is a DigiSpark rev2 / Model A. Using a current git checkout: 58caa36ba05e06799201ae4a088401dabdddb2c3 Using libusb gem version 0.4.0.

Bluebie commented 10 years ago

Looks like you're having communications trouble. The commandline 'micronucleus' tool is much better at recovering from communications errors than the ruby library, so I suggest you try and use that. It is the most well tested code.

sodabrew commented 10 years ago

Thanks, I'll try this tomorrow.

sodabrew commented 10 years ago

The commandline tool works great, so I'm unblocked from testing 1.10. I will take a look at the Ruby tool to see if it can be improved, but if not, maybe there should just be one tool.

ScottMansfield commented 10 years ago

I just went spelunking through the libusb gem source and (at least) tracked it down to a call to the native library. In my unprofessional opinion, Bluebie's right.

Question @sodabrew: Is it a consistent issue or something that only happens every once in awhile?

Question @Bluebie: What part of the commandline code does the error handling for this type of situation? The ruby might be able to handle it and recover as well.

Bluebie commented 10 years ago

Some of the error handling is in micronucleus lib, some is in the cli ‘micronucleus’ app. There’s a pretty common error immediately after an erase cycle, which you can recover from by ignoring it and just searching the USB bus until the device comes back online

— Bluebie

On Friday, 20 December 2013 at 10:55 am, ScottMansfield wrote:

I just went spelunking through the libusb gem source and (at least) tracked it down to a call to the native library. In my unprofessional opinion, Bluebie's right. Question @sodabrew (https://github.com/sodabrew): Is it a consistent issue or something that only happens every once in awhile? Question @Bluebie (https://github.com/Bluebie): What part of the commandline code does the error handling for this type of situation? The ruby might be able to handle it and recover as well.

— Reply to this email directly or view it on GitHub (https://github.com/micronucleus/micronucleus/issues/35#issuecomment-30978326).

sodabrew commented 10 years ago

Consistent problem; it happens at different specific byte counts within a range of +/- 1k of where I posted.

sodabrew commented 10 years ago

Thinking about it, this is a pretty typical type of error in network programming, too. You just retry it a few times :)

Bluebie commented 10 years ago

The error happening during the write cycle is probably a timing problem. If the PC-side sends a write request too soon, it crashes the usb connection (because micronucleus is not USB compliant, but usually it can get away with it by only being broken during times when the computer isn’t talking to it)

— Bluebie

On Friday, 20 December 2013 at 10:58 am, Aaron Stone wrote:

Consistent problem; it happens at different specific byte counts within a range of +/- 1k of where I posted.

— Reply to this email directly or view it on GitHub (https://github.com/micronucleus/micronucleus/issues/35#issuecomment-30978506).

sodabrew commented 10 years ago

I forgot about this ticket, since I started using the C commandline tool. I'll take another look at the Ruby code before too long.

cpldcpu commented 10 years ago

I changed the protocol in V2 a little, but it is not final yet. Basically it introduces the setup-only protocl idea by Embedded Creations. So some changes to the ruby tool may be necessary in the future to make it compatible