ATTinyCore 1.52 findings

[Pelleman2022]

Hello!
I have tried the AtTinyCore 1.52 lib, works really well and is super nice!
But, there are a few small snags that I have encountered, which probably can be fixed, so I thought I better report it here. Perhaps Spence will see it.
I have tried programming AtTiny84/a with this lib, using OptiBoot flashed using Arduino programmer. It works fine to burn the boot loader and upload the program once, sometimes twice, but then after that, when I do next upload, it complains about not being able to verify the content (error) in Arduino IDE and my uploaded program doesn't start.
After re-burning the bootloader, I can upload again, but it is a bit frustrating having to do it (almost) every time.
Also, another snag, only the 8mhz internal clock version works, the 1mhz internal clock version hangs the chip after boot.
I have tried 16Mhz external clock, it works fine.

[SpenceKonde]

Not sure why 1 MHz version is doing that. All the parts have new bootloaders (and often more resilient serial configurations - the baud rate for 16 MHz and 8mhz is down significantly on parts with hw serial, because the clock speed leads to significant baud rate error at the most popular baud rates, and the error happens to be in the direction that stacks with instead of counteracts the oscillator inaccuracy common on the 841, while software serial devices had baud rates set lower than was appropriate for reasons unclear.)) ready for 2.0.0. (yes, 2.0.0 will require all parts to be rebootloaded, that's why it's a major version).

Worth noting that ATTinyCore will come with approx 500 pre-built bootloader binaries. And we only provide bootloaders for what, 14 parts? I get away with 22 files on megaTinyCore, supporting a bootloader on 45 parts..... And on these godawful things, I need hundreds.

When you've got the chip failing if you could dump the flash to a hex file with an ISP programmer and get it to me that would be really helpful in figuring out what happens. A scope trace that shows an upload that is expected to fail,.. showing both TX and RX (set to take single frame, trigger on either rising or falling edge, then enable single trigger mode during upload, to capture a snapshot of the serial comms. Then either you verify, or save screenshot onto a flash drive (most modern scopes will do this), pressing the single trigger button on scope as soon as you see the serial activity light turn on. This allows us rule out general derangement of the software serial port, and know that a focus on the bootloader application behavior is

path/to/avrdude -c programmer-id -b baud-rate -C path/to/config/file -U flash:R:flashdump.hex:i

where programmer is likely usbasp, usbtinyisp, or arduino (for arduinoasisp), baud-rate is the baud rate, if applicable (19200 for arduino as isp, omit for usbasp and usbtinyisp). Get path/to/avrdude and path/to/config/file by running any ISP programming operation with verbose upload enabled (even if the part isn't connected, it'll show the command executed, and you can copy the paths from there). Run that in a command window and you should get a flashdump.hex containing the contents of the flash on the broken device.

Send that, the hex file you were uploading that failed (from sketch export compiled binary) and the full text of the verbose upload output that failed to me at spencekonde AT gmail,com. These sorts of things get sporadically reported, but I never get this key information, so I am never able to figure out what's going on.

The two hex files will give insight into what it's doing (if the bitwise and of each byte in export.hex, and the corresponding byte in dump.hex is equal to the byte from dump.hex, and the byte from export.hex >= the byte from dump.hex for all bytes up to the length of the shortest of the two, that indicates a failure to erase, localizing the bug to a tiny portion of the code.

The verbose output logs will tell how the core is invoking avrdude, and when it recognizes the problem.
And if you're able to get a scope capture, that allows me to rule in or rule out clock/baud rate error.

[SpenceKonde]

A few other comments:
Does it still happen in latest github version? (2.0.0dev) No further work is being conducted on old branches, and the goal is to get 2.0.0 out.

Also - you have set up autoreset right? In order to upload the chip has to be reset to allow the bootloader to run, otherwise it will only upload once;

If it reproduces in 2.0.0, please be sure to create an issue so that it is on my list of action items. (Issues list = action items. discussions do not need to get marked closed or deferred for a release) and check which speeds it happens at, because 2.0.0 adds a huge number of clock speed options for all devices, and knowing which speeds do and don't work would be incredibly valuable. (notice also just how bloody many bootloader binaries we supply now - almost 600 optoboot,. and over 300 micronucleus binaries get built) One of the changes was that I recalculated what smart baudrates to use would be different speeds this time, instead of just copying what others did, because it turns out others didn't know what they were doing. https://docs.google.com/spreadsheets/d/1uzU_HqWEpK-wQUo4Q7FBZGtHOo_eY4P_BAzmVbKCj6Y/edit?usp=sharing in th Classic AVR section shows the baud rate error for each system clock and baud rate assuming the system clock was exactly on target - that only applies to hardware serial but the window of viable speeds on software serial is even worse. I'm going to be coming back to work on ATTinyCore shortly to finish up the 2.0.0-dev release