Timing errors seem to accumulate about micronucleus HOT 4 OPEN

This is surely a weird behavior, but the oscillator is typically recalibrated every time you invoke micronucleus. The main purpose of saving the osccal calibration is to have a more accurate osccal setting for the user program. (unless @ArminJo changed this?)

There could be other issues with your set up. Are you using an USB hub or similar?

Otherwise: Can you try to recompile Micronucleus with changed settings and see whether the issue disappears? There is also the precompiled "T85_aggressive" hexfile that does not save the calibration at all.

from micronucleus.

Ok, I'll try different settings. But now I need to use ISP for that, I think, because I cant' reach micronucleus through USB any more.

from micronucleus.

(unless @ArminJo changed this?)

until today I do not really understand the side effects of this code and therefore I NEVER changed it.

But under extreme conditions (unstable oscillator, great drift, etc.) It eventually might lead to the error described by starting with a value where synchronisation is not possible.

int main(void) {
    bootLoaderInit();
    /* save default OSCCAL calibration  */
#if OSCCAL_RESTORE_DEFAULT
  osccal_default = OSCCAL;
#endif

#if OSCCAL_SAVE_CALIB
    // Adjust clock to previous calibration value, so bootloader AND User program starts with proper clock calibration, even when not connected to USB
    unsigned char stored_osc_calibration = pgm_read_byte(BOOTLOADER_ADDRESS - TINYVECTOR_OSCCAL_OFFSET);
    if (stored_osc_calibration != 0xFF) {
        // Start with latest OSCCAL value computed for 16.5 Mhz. 
        // This is required for applications running at F_CPU==16500000L and discarded by the application startup code if (F_CPU!=16500000L)
        OSCCAL = stored_osc_calibration;
        // we changed clock so "wait" for one cycle
        asm volatile("nop");
    }

@wolneykien Please report if the error has gone without this option.
Attached the t85default with #define OSCCAL_SAVE_CALIB 0

t85_default.zip

from micronucleus.

Hi !

Edit : read @ the end.

Same here with an ATTiny85, Micronucleus 2.5 from ATTinyCore : t85_entry_on_power_on_no_pullup_fast_exit_on_no_USB
On the 2-3 first plugs, it's was OK.
Then on the next plugs, sometimes it was OK, sometimes not recognized.
And now it's never recognized, even on others computers.

I guess this is a consequence of the particular OSCAL register on ATTinyX5, extract from the doc :

OSCAL Register on ATTinyX5:
The CAL7 bit determines the range of operation for the oscillator. Setting this bit to 0 gives the lowest frequency range, setting this bit to 1 gives the highest frequency range. The two frequency ranges are overlapping, in other words a setting of OSCCAL = 0x7F gives a higher frequency than OSCCAL = 0x80.
The CAL[6:0] bits are used to tune the frequency within the selected range. A setting of 0x00 gives the lowest frequency in that range, and a setting of 0x7F gives the highest frequency in the range.
To ensure stable operation of the MCU the calibration value should be changed in small. A variation in frequency of more than 2% from one cycle to the next can lead to unpredicatble behavior. Changes in OSCCAL should not exceed 0x20 for each calibration. It is required to ensure that the MCU is kept in Reset during such changes in the clock frequency.

For now I can't test another Micronucleus configuration : The RESET pin was set as an IO, so i need to build a high voltage programmer to reset the fuses.

Hope this hypothesis can help !

Edit : all seems OK after ~20 plug/unplug with custom compiled v2.6 (OSCCAL_SAVE_CALIB 1), so the problem comes either from the v2.5 or from the compiled version given with ATTinyCore. Thanks !

from micronucleus.