@mbrugman Reading an Arduino Mega works and then right after an Arduino Leonardo (ATmega32U4) doesn’t work.
dude.zip (11.2 KB)
2 Likes
Hmmm, I was able to go back and forth between 328p and 2560 with no problem.
I have some 32u4 parts around somewhere; I’ll try it tomorrow.
1 Like
@mbrugman Alright, I figured it out! We need to clearly state in the documentation that the Arduino must absolutely be connected via USB and powered — I ran some tests and the errors I was getting were because of that.
32uworkingdude.zip (41.6 KB)
2 Likes
retesting (arduino powered by USB)
arduino mega → works fine
arduino leonardo → works fine
arduino uno → works fine
I tried running them in sequence, changing the order, etc… and it all seems to work as expected. Great job @mbrugman ! You can go ahead and merge it as far as I’m concerned.
2 Likes
Interesting!
EDIT: I’m overthinking everything below, just ignore me, haha.
I was starting to remember something special about the u4 parts: the 32u4 part actually has more than 32k of flash!
There’s additional flash above 0x7fff set aside for a usb/dfu bootloader. I thought avrdude might be trying to read that, which would generate an error similar to what we were seeing with larger flash.
1 Like
@mbrugman It’s curious, isn’t it? In the logs, you can see that the MCU type does get detected over SPI, but then the SPI read page fails — and as soon as you power it via USB, voilà! It works!
With your PR The ATmega32U4 dump works fine — check out this photo:
avrdude.exe -c buspirate -p m32u4 -P COM12 -b 115200 -U flash:r:"C:\Users\regue\Desktop\dump.bin":r
attempting to initiate BusPirate binary mode ...
Paged flash write enabled
Reading flash memory ...
Reading | ################################################## | 100% 39.76 s
Writing 32730 bytes to output file dump.bin
Avrdude done. Thank you.
2 Likes
Thanks again for testing and for the sanity checks 
1 Like
@mbrugman Can you do me a favor? Could you power your boards only using the Bus Pirate’s VOUT at 5 volts, and try switching boards around to see if you get the same issue as I did? Maybe try plugging in a USB hub (not self powered) or something in between that slightly drops the Bus Pirate’s voltage?
1 Like
I did all my testing with only BP power - no USB, but I didn’t try a 32u4. I do use a powered hub, I can tra a different one
1 Like
@chickendipper - the fix for this is merged into the main branch now 
2 Likes
@dreg - I did some experimenting with 32u4 boards today; I had a few in my bin. To be fair, I tried them using AVRDude with both the Bus Pirate and the AVRDragon.
cmdline for the BP was:
avrdude -c buspirate -P /dev/ttyACM1 -p m32u4 -U flash:r:full32u4.BP1.bin
and for the Dragon:
avrdude -c dragon_isp -p m32u4 -U flash:r:full32u4Dragon1.bin
Here’s where it got a little funny… Of the 3 boards (all identical), one had to have the Leonardo’s USB connected - without it, the BP couldn’t read the Flash. The other two I could read the flash with the BP with the Leonardo’s USB connected or disconnected.
(For reference, the part has to be powered for the AVRDragon to work, so I had to have the Leonardo’s USB plugged in for all 3 to make the dragon work).
So, inconsistent, which is odd; but I did recreate your experience where you had to power the Leonardo board. 
2 Likes
Weird. 3 identical boards exactly the same, or with the same chip but different design?
The updates to legacy 4 third around the PSU seems to have been effective. I’m in a refactoring mood and think turning the pirate lib into a struct of functions might might be on the horizon. A kind of rework to a C++ like object framework.
2 Likes
Same model board, different firmware on each (which shouldn’t matter). Really odd, but who knows?
1 Like
@mbrugman Can you confirm that as soon as you connect the AVR board via USB, it always works?
2 Likes
Yes, that was the behavior I saw. Even disconnecting and reconnecting everything it worked for the “bad” board, as long as the USB was connected.
2 Likes
Alright… thank you so much for this, I was going a bit crazy haha. While we figure out what the actual issue is, I’m going to update the documentation.
2 Likes
The 32u4 (and 16u4) are pretty unique parts. Maybe the power requirements with the USB make it a bit flaky that way.
The dragon has no problems; but the dragon requires the target be powered before it’ll do anything.
2 Likes
By the way, it’s funny how we’ve turned @chickendipper ’s thread into a full-on Bus Pirate development thread — the poor user must be freaking out with all this stuff that doesn’t even interest them 
we’re unbelievable.
4 Likes
Thread derailment service at work again 
4 Likes
Hey, let’s be “modern” firmware engineers: Thread Takeover as a Service (TTaaS)! 
2 Likes