Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can "burn bootloader" be done in a single avrdude invokation? #372

Closed
SpenceKonde opened this issue Nov 30, 2019 · 2 comments
Closed

Can "burn bootloader" be done in a single avrdude invokation? #372

SpenceKonde opened this issue Nov 30, 2019 · 2 comments

Comments

@SpenceKonde
Copy link
Owner

If it is we should do it. There's no reason for multiple programming operations, and it causes problems with one uncommon programmer (was it the dragon?), and on the t841 and t1634, certain versions of the USBAsp firmware, some of which are found in the wild, appear to mishandle the reset pin, leaving it in a non-programable state until programmer is disconnected from reset. I don't know why it never happens on other parts, but I saw this back in 2016 and 2017 (though at the time I wasn't sure that the USBAsp firmware was at fault, as subsequent batches of USBAsps worked with the firmware they came with - though this doesn't mean much because multiple versions of the firmware are circulating on USBAsp clones), and then never saw it again and assumed I must have just been doing wrong. But a customer just reported the exact same behavior to me.

So this needs to be examined.

@SpenceKonde SpenceKonde added this to the 1.3.3 release milestone Nov 30, 2019
@per1234
Copy link
Contributor

per1234 commented Dec 1, 2019

Yes, it can be done. I have worked with an owner of an AVR Dragon to confirm that this fixes the problem.

I have a dummy hardware package that adds a AVR Dragon programmer using this technique. I'm a bit hazy on the details, but I remember there was some trickyness due to the way the Arduino IDE sources platform.txt, which I think I documented here:
https://github.com/per1234/InoAVRDragon#burn-bootloader-process
So that InoAVRDragon project is more of a workaround than an ideal solution. I think that would not be an issue when making this change directly in a real hardware package like ATTinyCore, since in that case the modified platform.txt is in the same package as the programmers.txt and the boards.txt files.

There is probably some more information buried in this thread:
per1234/InoAVRDragon#1
including discussion and testing of the "Real Fix", which was getting Arduino to modify Arduino AVR Boards platform.txt to do Burn Bootloader in one operation, which would be the same approach as the modifications needed to ATTinyCore. I have a proof of concept of that here:
https://github.com/per1234/SingleCommandBurnBootloaderDemo

I'm kind of swamped with work right now, but if this hasn't been resolved before I get caught up, I'll definitely refresh my memory on the work I did and see what I can do to help make this happen.

@SpenceKonde
Copy link
Owner Author

I think I can handle this part.

When you have time to throw at megaTinyCore - it's the initial travis prep that I need help with. Like, ones it's set up, I now know how to tweak it, but I don't know a good way to fix all the spacing and whitespace errors other than manually, So far it would have saved me 3 broken releases.

SpenceKonde added a commit that referenced this issue Dec 13, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants