Timing errors seem to accumulate

[wolneykien]

I have a device similar to shown in #144 . With the first 4-5 user code upload attempts it was all okay, the board was successfully enumerated by the USB subsystem:

usb 1-1.3: new low-speed USB device number 47 using xhci_hcd
usb 1-1.3: New USB device found, idVendor=16d0, idProduct=0753, bcdDevice= 2.06
usb 1-1.3: New USB device strings: Mfr=0, Product=0, SerialNumber=0

Then, however, it suddenly failed the enumeration:

usb 1-1.3: new low-speed USB device number 78 using xhci_hcd
usb 1-1.3: Device not responding to setup address.
usb 1-1.3: Device not responding to setup address.
usb 1-1.3: device not accepting address 78, error -71
usb 1-1.3: new low-speed USB device number 79 using xhci_hcd
usb 1-1.3: Device not responding to setup address.
usb 1-1.3: Device not responding to setup address.
usb 1-1.3: device not accepting address 79, error -71
usb 1-1-port3: unable to enumerate USB device
...

And then it constantly fails to be enumerated on that particular computer. I've thought it was some accident and moved to another workstation where the device had no enumeration problems… until now! Currently, the board constantly fails to be enumerated on that second computer (and on the first too).

So I wonder, could it be some sort of an error, possibly, a timing or a clock error, that constantly increases over time? For that to be true, there should be some non-volatile memory where the clock reference is saved and then restored on each power-on…

And then, examining the firmware configuration, I've found this:

*  OSCCAL_SAVE_CALIB         Set this to '1' to save the OSCCAL calibration during program upload in FLASH.
*                            This value will be reloaded after reset and will also be used for the user
*                            program unless "OSCCAL_RESTORE_DEFAULT" is active. This allows calibrate the internal
*                            RC oscillator to the F_CPU target frequency +/-1% from the USB timing. Please note
*                            that this is only true if the ambient temperature does not change.
*                            Adds ~38 bytes.

That is on by default in configuration/t85_default/bootloaderconfig.h.

Is it possible that this option leads to progressive degradation of clock/timings?

[cpldcpu]

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.

[wolneykien]

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.

[ArminJo]

(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

[Coethium]

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 !