ATtiny85 (optiboot) unreliable reprogramming

[heinerolli]

I am using an ATtiny85 with optiboot at 8MHz (internal) and I burned the booloader via Arduino as ISP.
I wired it with all optional capacitors and diode as described in here.
So, burning works and the first couple(!) of reprogrammings via serial work as well.
However, after the 3rd or 4th serial programming, it fails as it seems not to sync.
After doing a re-burn bootloader, ot worls again for 3 to 4 times.
(I need to reprogram often to tune some paramters of the program. Also, the ATtiny is enclosed, so reburning is a pain)
Any idea what is going wrong / how I can make serial programming more reliable?
(running at 1 MHz seems to be a bit more reliable, but I need 8MHz)

[pcfreak1201]

Hi heinerolli,
I had these problems with m168 (other core) because I didn't install the diode. But the t85 has no hardware-serial, may be it warms up after using it a time?

Warning: Internal oscillator and Serial Note that when using the internal oscillator or pll clock, you may need to tune the chip (using one of many tiny tuning sketches) and set OSCCAL to the value the tuner gives you on startup in order to make serial (software or hardware) work at all - the internal clock is only calibrated to +/- 10% in most cases, while serial communication requires it to be within just a few percent. However, in practice, a larger portion of parts work without tuning than would be expected from the spec. That said, for the ATtiny x4, x5, x8, and x61-family I have yet to encounter a chip that was not close enough for serial using the internal oscillator at 3.3-5v at room temperature - This is consistent with the Typical Characteristics section of the datasheet, which indicates that the oscillator is fairly stable w/respect to voltage, but highly dependent on temperature.

Did you try the 16MHz with PLL? Same problems?

[SpenceKonde]

When it fails, dump the contents of the flash to a hex file and post or send that to me for analysis. If it was working, and now is is not , and rewriting the flash makes it work a few times again, well, something is going wrong with what is written to the flash. I have a theory about what peroblem you are encountering..... (a deep bug in the implementation of virtual boot - the primary symptom is the first page being erased but not replaced. It happens due to brown-out or other interrupting early in programming. solution to this is to completely rework virtual boot-the current method stores all vectors in the first page to be erased. so if anything goes wrong on that first page (which is the most likely place fore things TO go wrong) both app and bootloader are hosed. There is only one way this works, and micronucleus figured it out and implemented it ages ago - the application vector is the last byte before the bootloader section, and when you know you're going to erase anything, you erase the entire flash, starting from high addresses, and ending at the first page which contains the reset vector. That way, if it fails at any point in erase process - app vector gone, it runs bootloader, no problem. If it fails at maximal erasure? No problem, that's what you get when you bootload, and if it fails while uploading, the app vector hasn't been written yet

[heinerolli]

Thanks for the detailed reply.
When it fails again, I will try to get the information to you.
Can you give me a hint how to retrieve that hex file - esp in the "fail" case, where serial seems not to sync anymore?
Also, another question wrt "tuning" ATtinys clock frequency: I never did this so far - as my understanding was that this tunes the behavior during running the program, but not for serial programming. - is there a way to optimize clock frequency also during serial programming? And if so - how?

.... I just realized a stupid mistake on my side: When doing serial programming, I still had something connected to PB1/Pin6 (Dout from a HX711 module) That can cause trouble, I assume....
In my next reprogramming iterations, I will disconnect that and report back, if that makes a difference.
(Reporting might take a while, as I am away from home for a while...)

[SpenceKonde]

Is that one of the serial pins? If so, yeah that would hose serial uploads, and of course be a great way to make the bootloader malfunction and trigger its bug, too!

…

____________ Spence Konde Azzy’S Electronics New products! Check them out at tindie.com/stores/DrAzzy GitHub: github.com/SpenceKonde ATTinyCore: Arduino support for almost every ATTiny microcontroller Contact: ***@***.***

On Tue, May 4, 2021, 04:16 heinerolli ***@***.***> wrote: Thanks for the detailed reply. When it fails again, I will try to get the information to you. Can you give me a hint how to retrieve that hex file - esp in the "fail" case, where serial seems not to sync anymore? Also, another question wrt "tuning" ATtinys clock frequency: I never did this so far - as my understanding was that this tunes the behavior during running the program, but not for serial programming. - is there a way to optimize clock frequency also during serial programming? And if so - how? .... I just realized a stupid mistake on my side: When doing serial programming, I still had something connected to D1 (Dout from a HX711 module) That can cause trouble, I assume.... In my next reprogramming iterations, I will disconnect that and report back, if that makes a difference. (Reporting might take a while, as I am away from home for a while...) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#556 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTXEW23BGYXJH5NWBEPNDLTL6UNXANCNFSM44BI43AA> .