Bootloader support for 44/84, 45/85, 461/861, 48/88

[aster94]

It would be helpful to have the bootloader also on the x4, it exist for the x41, so maybe it could be added without too much effort even if the x4 lacks of serial

[SpenceKonde]

Differences are considerable due to the lack of hardware serial.
Can someone convince me that offering a necessarily bloated bootloader that uses software serial is a good use of resources, ie, that it will offer a decent value for the users?

[sleemanj]

For reference it requires 582 bytes (or at least that's what I reserve for it in my fork which does support the x4 for bootloading).

https://github.com/sleemanj/optiboot/blob/master/optiboot/bootloaders/optiboot/Makefile.attinyx4

[aster94]

I will try it! Anyway if sleemanj is ok with this maybe dr Azzy could add the support using your code and referring to your repo

I am just saying i don t know if it could be a problem for any

[SpenceKonde]

If this goes into the core:

• It should be a new entry in the board menu, eg, ATTiny84 (Optiboot)
• We need to decide on a consistent system for which pins to use - I would suggest AIN0/AIN1, so that the built-in software serial named Serial can be used without moving connections.
• Support should be added for the 85, 84 and 861, at a minimum
• We need to figure out how to make absolutely clear to the users the necessity of using an external crystal (or solve Add sketch for tuning the internal oscillator #139 and provide clear documentation).
• All pull requests should go into a new branch for proper testing before they go into master.

I will not have any time to devote to development or test of this in the near future, as there are far more pressing concerns - #116 is the only outstanding issue that will be addressed by me for the next version, beyond a bit more testing of the I2C stuff - of course, as always I would welcome pull requests to add this stuff in (just not for 1.1.3, which I want to get out the door ASAP).
I think documentation is probably the bigger hurdle than just making Optiboot work - as I noted above, a new feature that produces shitloads of support inquiries due to inadequate documentation or reliability issues is the last thing I need.

[SpenceKonde]

Also - I do not feel that a bootloader for the smaller versions of the x4, x5, x61 series makes sense for the user. The 4k chips are already extremely cramped for space when used with the Arduino IDE; the 2k ones are out of the question. Anyone care to convince me otherwise, go ahead.

[aster94]

Ok i understand, never mind

anyway (maybe there is a reason but i m not aware of it) i would suggest you to move the choosing of the bootloader to a menu entry after the user already choose the mcu

If i am not been enough clear i would suggest you to have a look to the stm32duino repo:
There you select the mcu, than you choose the upload method and type of bootloader

[SpenceKonde]

I don't think it's possible to make a submenu selection change the available options on another submenu - this would be a better way if it were possible, but I don't think it is.

[cellularmitosis]

Hello,

First, thanks so much for working on this! Lots of great improvements recently.

After some sleuthing I have figured out how to enable the unsupported bootloader for the attiny85. However, it appears to get stuck in a loop. It looks like it was meant to run TinyTuner once on the first boot, but it appears to run it on every boot:

Entering Tiny Tuner

Poor Man's Internal Oscillator Tuner
Slowly send lowercase 'x' to tune the oscillator...

Current Calibration = N
Lets see if we can do better

Current Cal = E
Current Cal = H
Current Cal = I
Current Cal = H
Current Cal = H
Current Cal = G
Current Cal = G
Current Cal = G
Current Cal = I
Current Cal = I
Current Cal = G


Final Cal = G
Saving Calibration to Program Memory...
Removing call to TinyTuner to reduce bootloader size by 2.3kbytes
Calibration saved and TinyTuner Deleted


Enabling Bootloader and Rebooting

Entering Tiny Tuner

Poor Man's Internal Oscillator Tuner
Slowly send lowercase 'x' to tune the oscillator...

Current Calibration = G
Lets see if we can do better

Current Cal = H
Current Cal = I
Current Cal = H
Current Cal = H
Current Cal = G
Current Cal = G
Current Cal = G
Current Cal = I
Current Cal = I
Current Cal = G


Final Cal = G
Saving Calibration to Program Memory...
Removing call to TinyTuner to reduce bootloader size by 2.3kbytes
Calibration saved and TinyTuner Deleted


Enabling Bootloader and Rebooting

Entering Tiny Tuner

Poor Man's Internal Oscillator Tuner
Slowly send lowercase 'x' to tune the oscillator...

Current Calibration = G
Lets see if we can do better

Current Cal = H
Current Cal = I
Current Cal = H
Current Cal = H
Current Cal = H
Current Cal = H
Current Cal = H
Current Cal = H
Current Cal = G
Current Cal = G
Current Cal = G
Current Cal = I
Current Cal = I
Current Cal = G


Final Cal = G
Saving Calibration to Program Memory...
Removing call to TinyTuner to reduce bootloader size by 2.3kbytes
Calibration saved and TinyTuner Deleted


Enabling Bootloader and Rebooting

Entering Tiny Tuner

Poor Man's Internal Oscillator Tuner
Slowly send lowercase 'x' to tune the oscillator...

Current Calibration = G
Lets see if we can do better

and so on.

It appears it is not successfully deleting TinyTuner. Does anything come to mind which might prevent the bootloader from deleting TinyTuner? Perhaps some fuse bit is not set correctly?

Also, I'm not sure I understand the argument of not offering a bootloader for e.g. attiny85. If you offer the bootloader, people who need it can use it, and people who think it requires too much space will continue to ignore it. Maybe I don't understand the situation, but it seems like offering the bootloader has no down-side at all.

In fact, I would argue quite the opposite -- disabling the booloader represents anti-value to the user. It took me several evenings of "internet research" just to figure out how to re-enable the unsupported bootloader. It was very confusing and frustrating to have an option in the IDE labelled "Burn Bootloader", but it actually uploaded "empty.hex", which appears to do nothing at all.

If you need some help with testing out support for the x5 chips, I'd be happy to lend a hand!

Thanks,
Jason

[cellularmitosis]

I compiled a bunch of bootloaders for the attinyx5 series using the @sleemanj fork of optiboot linked in his comment above.

hex files here:

https://github.com/cellularmitosis/attiny85-bootloaders

It looks like the bootloader is working (it reads the hex file over serial), but I'm getting a checksum error when the IDE reads the hex back from the bootloader:

avrdude: Device signature = 0x1e930b (probably t85)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "/var/folders/69/72d4xkfd1590xchmw2dpttmm0000gn/T/arduino_build_123194/hello.ino.hex"
avrdude: writing flash (1340 bytes):

Writing | ################################################## | 100% 0.87s

avrdude: 1340 bytes of flash written
avrdude: verifying flash memory against /var/folders/69/72d4xkfd1590xchmw2dpttmm0000gn/T/arduino_build_123194/hello.ino.hex:
avrdude: load data flash data from input file /var/folders/69/72d4xkfd1590xchmw2dpttmm0000gn/T/arduino_build_123194/hello.ino.hex:
avrdude: input file /var/folders/69/72d4xkfd1590xchmw2dpttmm0000gn/T/arduino_build_123194/hello.ino.hex contains 1340 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.84s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0002
         0xff != 0x33
avrdude: verification error; content mismatch

avrdude done.  Thank you.

It looks like it is happening very early on (byte 2?), so something fundamental might be wrong.

Which programmer protocol does the optiboot bootloader use? arduino?

[cellularmitosis]

I got it to work!

It turns out the fused were wrong in boards.txt. Specifically, the extended fuses prevented the attiny from being able to write to flash, so it was never able to write the hex file which was sent to it.

Changing the extended fuses from 0xFF to 0xFE in boards.txt fixes the issue:

attinyx5.bootloader.extended_fuses=0xFE

I'll submit a pull request shortly.

[SpenceKonde]

Looks like you haven't adjusted the fuses to permit self programming? LSB in the EFuse needs to be set to 0 to use self programming (ie, a bootloader)

The bootloaders for these parts predate my work on this project, and last time I tried I was unable to figure out how to make them work. They were pulled from the core at that time, since they were a low priority. It seems that you have gotten further than I ever did.
Leaving code that I know or expect to not work is unprofessional and would result in support inquiries from people who expect it to work (I field a lot of support inquiries that are not publically viewable) - that is why I had no choice but to remove the old bootloaders.

I am pretty sure that there is a bug in the virtualboot implementation, at least the one in bootloaders-unsupported. Symptom of this would be a successful write (possible failed validation, possibly not), but either the application not starting, or the bootloader never running again, or both - flash contents would need to be dumped via ISP and examined after a write, with particular attention to the interrupt vectors (virtualboot is used to provide bootloader functionality on parts without a BOOTRST fuse - it works by rewriting the reset and wdt interrupt vectors while the flash is being written and read).

Re: "Burn Bootloader" - like the default arduino core "Burn Bootloader" means to write fuses, and write any bootloader to the flash. I would love it if I could change this to read "Write Fuses" on parts that didn't have a bootloader or where a bootloader was not selected. But there unfortunately does not appear to be any way to change what it displays.

The empty hex file (which isn't quite empty - it's got 2 bytes in it, because avrdude will reject the command if you pass it a truly empty hex file) is a workaround; the issue is how to support parts with and without a bootloader with the same recipes in platform.txt . I have an idea of how to get rid of the empty hex files, but 1.1.5 release is a much higher priority currently.

If you'd like to take on this project, I'd appreciate the contribution. I am still convinced it would require a separate board def (for x4, x5, x61, and x8 - the boards that don't have a hardware serial port) , and it would need to handle all the reasonable clock rates, and include tinytuner when the board is set to use internal oscillator. We would also need to document use of tinytuner.