You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
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.
The text was updated successfully, but these errors were encountered: