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.com<mailto: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/embedded-creations/USBaspLoader-tiny85/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.com<mailto:notifications@github.com> wrote:

Mac OS X 10.8.1

— Reply to this email directly or view it on GitHubhttps://github.com/embedded-creations/USBaspLoader-tiny85/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.com<mailto: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/embedded-creations/USBaspLoader-tiny85/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 (https://github.com/embedded-creations/USBaspLoader-tiny85/issues/1#issuecomment-8324653).

[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.

[embedded-creations]

I had similar errors with OSX, but it worked in parallels. I haven't thought of a reason why yet, and can't dive into the code right now.

Louis

On Sep 6, 2012, at 6:35 PM, Jenna Fox notifications@github.com<mailto:notifications@github.com> wrote:

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

— Reply to this email directly or view it on GitHubhttps://github.com/embedded-creations/USBaspLoader-tiny85/issues/1#issuecomment-8353401.

[Bluebie]

Oh hey I just got lucky uploading a 340 byte program - the first time it had one FFFF word, second time it had none and ran fine! Okay, so at least we can rule out some weird logic error where only certain hex files break. It does seem to be a properly random behaviour.

[Bluebie]

Yeah that's cool, I'm mostly just using this thread to take notes - scientific journal type of thing.

[cjb]

I tried the same, but adding a usleep of any duration after the second call to usbasp_transmit() doesn't help me avoid the "broken pipe" errors, many of which happen outside of usbasp_spi_paged_write().

(I'm on Linux.)

[Bluebie]

One interesting tidbit I don't understand yet - It seems every time I upload a program which has one or more missing words, the attiny stays with the bootloader, not seeming to ever get stuck inside a broken program. Not sure what to make of that. Could it also be failing to write the final interrupt vector table stuff? Need to dump more flash and see what's going on. Also, how could it be missing just two bytes? The page size on tiny 45 and tiny85 is 64 bytes each - so I'd expect it to be missing 64 bytes if it was a usb error? @embedded-creations do you have any ideas what parts of the upload process work in two-byte chunks? This is what has me suspect there may be an off by one (word) error somewhere in the avrdude code which only shows up when the blocksize = page_size in usbasp_spi_paged_write. Still the randomness weakens this idea a lot. To check how random the errors are, I uploaded some /dev/random to the chip repeatedly, then dumped it and compared the output, graphing it in to a png you can see here (it's rather long - zoom in) http://d.pr/i/wGOo

Along the vertical axis are my nine tests, and along the horizontal are each word of the program represented as a single pixel. Red dots are 'this word is entirely wrong', blue are 'this word is wrong and it's FFFF', and light grey are correct matching words. I think it's a little bit interesting that in all of my tests there were no FFFF's in the very last section, and no bytes were corrupt (aside from the mangled interrupt vector table at the beginning)

Just as another thought - I wonder if the flash writing process is messing up the PLL clock somehow and causing the AVR to become slightly out of sync with the host machine with some USB controllers and not others? I wonder if this problem might go away if that auto recalibration function were rerun after each page. Might be worth a shot?

[embedded-creations]

Hi Jenna. There's a checksum calculated on data received over USB and written to the end of application space. If it doesn't match, then the boot loader stays in boot loader mode, waiting for a valid program to be uploaded. That gives us a clue as to what's going on, it seems the data received over USB by the V-USB library is different than what is written to flash. If there was an error in the data received by V-USB, then the checksum should match and the boot loader would jump to the application. Data is written to flash in words, not bytes, so the pair of 0xFFFF's make some sense. I assume the error is always on an even byte address, never odd. Interesting thought on the PLL. Sorry I can't spend any more time on this right now… Louis

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

Along

[Bluebie]

I tried something a bit dodgy. I changed this line in usbasp_spi_paged_write:

n = usbasp_transmit(pgm, 0, function, cmd, buffer, blocksize); usleep(8000);

to this:

n = usbasp_transmit(pgm, 0, function, cmd, buffer, blocksize); usleep(8000); n = usbasp_transmit(pgm, 0, function, cmd, buffer, blocksize); usleep(8000);

And now when I run my tests, there are no more FFFF's. Kinda counting on the idea that writing the same bits to flash twice shouldn't do anything, so long as they really are the same bits. The ISR table still appears different between read and write, and my program doesn't seem to ever run, so it seems you're right about the bootloader noticing something went wrong with USB and decided not to enable the program - it stays in bootloader even after avrdude successfully verifies with this mod, and doesn't run my uploaded program after power cycling the bootloader either. This terrible work around feels so close to working!

[embedded-creations]

Cool hack, you're getting close! The checksum is failing because it's calculating the checksum for the app twice (you're writing to flash twice), and writing that computed checksum to flash. Later on before booting it calculates the checksum and it won't match. You could disable the checksum feature fairly easily right now, but I wouldn't recommend shipping that version of the boot loader with your project. We could add logic to only calculate the checksum if it hasn't covered that section of flash already, allowing for repeated writes, but that adds to code space, and I'd rather find the actual problem and fix it. We could have the firmware take care of the repeated writes, or add logic to verify what was written to flash, but again, I'd rather find the actual problem.

Louis

On Sep 7, 2012, at 6:22 PM, Jenna Fox notifications@github.com<mailto:notifications@github.com> wrote:

I tried something a bit dodgy. I changed this line in usbasp_spi_paged_write:

n = usbasp_transmit(pgm, 0, function, cmd, buffer, blocksize); usleep(8000);

to this:

n = usbasp_transmit(pgm, 0, function, cmd, buffer, blocksize); usleep(8000); n = usbasp_transmit(pgm, 0, function, cmd, buffer, blocksize); usleep(8000);

And now when I run my tests, there are no more FFFF's. Kinda counting on the idea that writing the same bits to flash twice shouldn't do anything, so long as they really are the same bits. The ISR table still appears different between read and write, and my program doesn't seem to ever run, so I it seems you're right about the bootloader noticing something went wrong with USB and decided not to enable the program - it stays in bootloader even after avrdude successfully verifies with this mod, and doesn't run my uploaded program after power cycling the bootloader either. This terrible work around feels so close to working!

— Reply to this email directly or view it on GitHubhttps://github.com/embedded-creations/USBaspLoader-tiny85/issues/1#issuecomment-8383361.

[embedded-creations]

I picked up this issue as I'm about to lose my Windows machine and need the bootloader to work on my Mac. Putting "live" updates here instead of taking notes elsewhere:

I added debugging output to the boot loader, using the USI in 3-wire mode, and monitoring SPI output with a logic analyzer. I'm using the bootloader to load a text file which doesn't contain any FF's to the chip. I had writeFlashPage() function read back what was just written to flash, and print out the address over SPI when it reads back 0xFF. It prints out the same address as AVRDUDE of the first mismatch (in addition to some addresses in the first page which is written with vectors just after flash erase).

Next I looked for 0xFFs in writeWordToPageBuffer(), right before it calls boot_page_fill(), the only place where data is written to the "Temporary Buffer" use for SPM. There aren't any 0xFFs written aside from the first page and addresses past the size of the file I'm using for testing. We can rule out data corruption over USB at this point. ...

[embedded-creations]

I then had the writeWordToPageBuffer() function send the CURRENT_ADDRESS variable over SPI, so I could see if the address of the mismatch was written to or skipped, and in two tests, the address was written to.

On a hunch, I tried doubling the call to boot_page_fill() so the page is filled twice, and after this change, got 5 successful verifications in a row. Seems the problem lies here.

[embedded-creations]

Solution: Need to disable interrupts before calling boot_page_fill(). According to the datasheet, you need to "execute SPM within four clock cycles after writing SPMCSR", and there's no way to guarantee that happens when interrupts are enabled.

There's probably other places in the code where the SPMCSR register is written to and interrupts should be disabled, I'll go and look for others.

[Bluebie]

@embedded-creations Could you upload your revised working build to this repository? I think I'm having a little trouble reproducing it as I'm using gcc4 and it seems to have trouble building the bootloader compactly, even unmodified - though it works if I change the bootloader address to make it even fatter. :/

Thanks for all the help. Very glad of this project. :)