avrdude patch incomplete

[Bluebie]

Seems the avrdude patch file was replaced with a newer patch which depends on the older file, or something like that.

[embedded-creations]

Hi, nothing has changed in 5 months, and there's no new AVRDUDE release. What's the issue you're seeing when you try to apply the patch?

Louis

[Bluebie]

Maybe I'm wrong, but https://github.com/embedded-creations/USBaspLoader-tiny85/blob/8a453da5cd9c0bde86be3a1ebed9ae545e941f83/software/avrdude-5.11.1-tiny85mods/avrdude.patch seems to be a new patch which depends on having already applied this patch: https://github.com/embedded-creations/USBaspLoader-tiny85/blob/3ef1f2078eba316fb41740861e514f96bd5bc12e/software/avrdude-5.11.1-tiny85mods/avrdude.patch

Regardless the current patch doesn't work for me - when I built it using only the current patch, I would get many broken pipe errors during upload, and the upload would go extremely quickly. By adding the usleep on line 36 of the old patch, I managed to avoid the broken pipe errors, but uploads still fail verification with output like this: https://gist.github.com/3647915 - uploading arbitrary hex files using this modified avrdude build and a real usbasp programmer still works fine - no verification errors, albeit slower than usual. I figure I must be having some trouble trying to apply the patch. It'd be preferable to me at least if you simply included the full modified usbasp.c file, or even created a new repo with a full copy of avrdude.

My hardware is an ATTINY85-20PU running at full 5v with zenner voltage limiters - works fine for other usb projects.

Thanks for the help. This project is very impressive and will help me immensely if I can get it working in the next few weeks. :)

[embedded-creations]

Hi Jenna,

Which OS are you running?

Louis

Sent from my iPhone

On Sep 5, 2012, at 4:58 PM, "Jenna Fox" <notifications@github.commailto:notifications@github.com> wrote:

Maybe I'm wrong, but https://github.com/embedded-creations/USBaspLoader-tiny85/blob/8a453da5cd9c0bde86be3a1ebed9ae545e941f83/software/avrdude-5.11.1-tiny85mods/avrdude.patch seems to be a new patch which depends on having already applied this patch: https://github.com/embedded-creations/USBaspLoader-tiny85/blob/3ef1f2078eba316fb41740861e514f96bd5bc12e/software/avrdude-5.11.1-tiny85mods/avrdude.patch

Regardless the current patch doesn't work for me - when I built it using only the current patch, I would get many broken pipe errors during upload, and the upload would go extremely quickly. By adding the usleep on line 36 of the old patch, I managed to avoid the broken pipe errors, but uploads still fail verification with output like this: https://gist.github.com/3647915 - uploading arbitrary hex files using this modified avrdude build and a real usbasp programmer still works fine - no verification errors, albeit more slowly. I figure I must be having some trouble trying to apply the patch. It'd be preferable to me at least if you simply included the full modified usbasp.c file, or even created a new repo with a full copy of avrdude.

My hardware is an ATTINY85-20PU running at full 5v with zenner voltage limiters - works fine for other usb projects.

Thanks for the help. This project is very impressive and will help me immensely if I can get it working in the next few weeks. :)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-8318129.

[Bluebie]

Mac OS X 10.8.1

[embedded-creations]

I did all my testing with Windows, but recently got a Mac. I'm gathering from your notes and some of the comments on my site that there are issues with my AVRDUDE modifications on Linux and OSX. I'll try it myself with OSX and maybe Linux when I get some time. If this is critical for you and time-sensitive, I wouldn't depend on finding a solution, it may not be easy to get this to work.

About your earlier comment, I don't think the issue is related to applying the patch correctly, I think it has to do with driver differences between Windows and OSX/Linux.

Louis

On Sep 5, 2012, at 6:04 PM, Jenna Fox <notifications@github.commailto:notifications@github.com>
wrote:

Mac OS X 10.8.1

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-8319256.

[Bluebie]

Okay. I'll give your windows binary a go - I can probably sort out some sort of system where a windows computer or vm does the uploading as a temporary solution. It isn't too time critical and hopefully software updates will be a rarity. I'm building some interactive art which makes use of analog radio and will likely require a bit of calibration in the field is all. Maybe the digispark guys will release their firmware before I need to close this thing up, as they seem to have sorted out cross platform programming. I just wish they were a bit more open in their development process. If all else fails there are those little serial bootloaders :)

[embedded-creations]

Do you have a link with steps to build AVRDUDE in OSX? I'm extremely new to OSX and Linux so any pointers would save me from a bunch of googling and trial and error.

Thanks,
Louis

On Sep 5, 2012, at 6:21 PM, Jenna Fox <notifications@github.commailto:notifications@github.com>
wrote:

Okay. I'll give your windows binary a go - I can probably sort out some sort of system where a windows computer or vm does the uploading as a temporary solution. It isn't too time critical and hopefully software updates will be a rarity. I'm building some interactive art which makes use of analog radio and will likely require a bit of calibration in the field is all. Maybe the digispark guys will release their firmware before I need to close this thing up, as they seem to have sorted out cross platform programming. I just wish they were a bit more open in their development process. If all else fails there are those little serial bootloaders :)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-8319520.

[Bluebie]

On linux you'll need to install libusb-compat from whichever package manager, then download the avrdude source and open a terminal, cd in to that directory and run:

./configure
make
sudo make install

and it should build and install

On Mac OS X, go in to the Mac App Store and download Xcode, open Xcode then press the command key and , together, and go to the Downloads tab. Press the Download button to the right of Command Line Tools - this will download and install llvm, clang, and the rest of the unix devtool stuff at a system wide level. Once the devtools are installed, pop over to http://mxcl.github.com/homebrew/ and do the one line install to get the homebrew package manager. Once homebrew is installed type 'brew install libusb-compat' (or even just brew install avrdude) and it'll grab your dependancy. Then you should be able to configure, make, and make install in the same way as on linux. You can do this without the homebrew package manager, but really it is the best thing around currently, and is very popular with mac developers.

[Bluebie]

For whatever it's worth, your binary version of avrdude.exe for windows doesn't work in VMware Fusion with it's usb bridging stuff. It looks like this: https://gist.github.com/3650904 - wacky, though I didn't really expect it to work well.

[Bluebie]

Interestinger still, booted in to windows 7 on my Mac Mini, setup usbasp drivers, got it working with my asp programmer, and then tried to use the exe supplied in this repository and it failed with very similar errors to my attempts on Mac OS! It wrote to flash suspiciously fast, then I heard the 'dun dun... doo dun!' sound of a usb device being unplugged and reconnected in windows, and avrdude errored at about the same time saying this:

avrdude.exe: verifying ...
avrdude.exe: verification error, first mismatch at byte 0x004c
0x49 != 0xff
avrdude.exe: verification error; content mismatch

Each time I run it, it behaves the same, making the disconnect sound and providing a verification error, but each time the error has a different value for the "at byte 0x004c" address section, and a different value for the 0x49 != 0xff (it always has 0xff on the right side of the operator though.

This happens regardless if I connect the t85 via the usb hub in my monitor or directly to the back of the computer. I've never had any trouble before using vusb devices on either of these ports, and I'm using a prototyping cable I've used in earlier projects which includes the resistors and zenners required, so the only electrical difference between this and other projects which have worked fine over usb ports on this computer are the particular attiny85 chip I'm using, and the bootloader firmware. Maybe there's some bug in the avrdude.exe patch which is dependant on host CPU speed to show up? I'm running on a Duel Core i7 clocked at 2.7GHz. - this machine specifically: http://www.apple.com/macmini/specs.html (the one on the right, with the optional cpu and ram upgrades to i7 and 8gb ram) I've also tried my Mac build on a lower spec'd macbook air and reliably have the same verification error (I don't have a windows partition on that machine). Thinking maybe it was to do with the usb hubs inside these computers which connect up things like the keyboard, trackpad, sd card reader, bluetooth baseband, but no luck - connecting it to a root hub usb port which has no other devices internally connected has the same broken behaviour.

[embedded-creations]

Progress:

Using your excellent instructions, I was able to get avrdude to compile on my Macbook. (One tweak, I did have to use 'brew install libusb-compat', it wasn't picked up as a dependency, and would compile a version of AVRDUDE with no usb support).

After finding I couldn't communicate with any USBasp programmer using AVRDUDE, I tried plugging both a mega8-based USBasp programmer and then a tiny85 boot loader into a USB hub, and both worked. I guess my Macbook has issues, luckily I read about this a couple weeks ago and knew to try the hub.

Now that I could communicate with the boot loader I started getting the broken pipe error after trying to program an application. I tried using Parallels with Windows 7 and MingW tools, same issue.

I used a logic analyzer to compare the USB traffic with a Lenovo laptop running Windows7 and MingW (how I did my development on this project), to the Parallels/Win7 setup, and it looked like there were fewer delays in the Parallels environment.

I put a 100ms delay after the second 'usbasp_transmit()' call in 'usbasp_spi_paged_write()' and the parallels/mingw environment was able to program the application, no broken pipe errors, successful verification. I made the same changes in the OSX environment and didn't get broken pipe errors, but did get verification errors in random locations.

This seems solvable, I just won't have time to continue on it for a while. If you're able to work on it yourself let me know what you find.

Louis

[Bluebie]

Ah that is good news! Unfortunately I don't have a logic analizer or any other useful USB debugging tools, so all my usb experiments so far have been by taking working vusb projects and slowly modifying them till they work. With no good way to get information out of the tiny85 about what's going wrong, or any more detailed information from the host computer, I feel like anything I did try to do would be only slightly better than random movements. Still, I'll certainly let you know if I do figure anything out, and I might pester the digistump guys for advice too. Glad the instructions helped. :)

—
Jenna

On Thursday, 6 September 2012 at 5:33 PM, embedded-creations wrote:

Progress:
Using your excellent instructions, I was able to get avrdude to compile on my Macbook. (One tweak, I did have to use 'brew install libusb-compat', it wasn't picked up as a dependency, and would compile a version of AVRDUDE with no usb support).
After finding I couldn't communicate with any USBasp programmer using AVRDUDE, I tried plugging both a mega8-based USBasp programmer and then a tiny85 boot loader into a USB hub, and both worked. I guess my Macbook has issues, luckily I read about this a couple weeks ago and knew to try the hub.
Now that I could communicate with the boot loader I started getting the broken pipe error after trying to program an application. I tried using Parallels with Windows 7 and MingW tools, same issue.

I used a logic analyzer to compare the USB traffic with a Lenovo laptop running Windows7 and MingW (how I did my development on this project), to the Parallels/Win7 setup, and it looked like there were fewer delays in the Parallels environment.
I put a 100ms delay after the second 'usbasp_transmit()' call in 'usbasp_spi_paged_write()' and the parallels/mingw environment was able to program the application, no broken pipe errors, successful verification. I made the same changes in the OSX environment and didn't get broken pipe errors, but did get verification errors in random locations.
This seems solvable, I just won't have time to continue on it for a while. If you're able to work on it yourself let me know what you find.
Louis

—
Reply to this email directly or view it on GitHub (#1 (comment)).

[Bluebie]

Progress! I uploaded my nyan-cat firmware via ISP, dumped it to a hex file, then uploaded USBaspLoader and uploaded nyan-cat it through the bootloader, failing verification at a random spot, and dumped that through an ISP. Turns out, the version uploaded through USBaspLoader is nearly identical - except for four things: Obviously the interrupt table at the beginning is a little different, and of course there's the bootloader appended at the end, but there are also two sections of the program where a word is FFFF instead of it's correct value. So, still an uploading timing issue I guess. Encouraging that the upload is mostly succeeding - we're close!

[Bluebie]

Using 8ms as delay after the second usb_transmit in usbasp_spi_paged_write instead of 100ms doesn't create any more errors for me, and 200ms is no better than 100ms. Still no progress tracking down why random words get corrupted, and still haven't gotten lucky and had none. Seems to always be at least two. Wondering if maybe my usb cable is dodgy - will follow that up soon.

[Bluebie]

Not corrupted, but rather do not get written. The incorrect words are always FFFF - I've never seen any corruption.