Digispark uses an RC oscillator which is tuned at startup to the precise pulses given out by your computer's USB port. This tuning is temperature dependant and so if the temperature of the digispark is changing substantially during the upload, that could cause it to go out of sync with the USB port and cause an error, maybe. I don't think the bootloader does constantly try to resync with the port, IIRC it just calibrates at startup - this is because it is presumed it will be done after five seconds or so, which shouldn't be enough time for things to drift enough to cause trouble, but perhaps I was wrong?
What sort of ambient temperature are the rooms where you use your digisparks? Are there any hot exhaust fans blowing near your USB ports? The refridgerator trick is really weird because effectively it is subjecting the digispark to extreme temperature changes during the upload, which should really be a bad thing.
It looks like you're using an old version of micronucleus. Erase errors shouldn't return -1 anymore, and should reattempt upload on all platforms. Can you try using the recently released 1.0.4 version of the Digispark software, or compile a fresh copy of the micronucleus software from my github page?
Do you get any errors in your system console to do with USB? (App called Console on mac, localed in /Applications/Utilities, or use 'dmesg' on linux, I already figured out you aren't using windows which is good because I don't know of any system console thing on there anyway and know nothing about how to debug windows issues!)
As a metanote, I would caution that erasing errors almost never are serious - they're the USB link bugging out. The digispark has always erased it's memory successfully anyway - the erase progress indication is just a timer, it isn't even talking to the digispark during the erase at all! So the right thing for the upload tool to do is to reconnect to the device and continue the upload automatically. It used to be not very good at doing that. It's been improved recently. The main trouble is that I almost never get these erase errors on my own computers so it's hard for me to work around, but I think it's getting better. Maybe one day someone can figure out why they happen in the first place! Maybe erasing the flash memory uses so much power that it heats up the CPU die so much that afterwards the clock speed is wrong! I don't think so though - I've tried making a version of the bootloader which recalibrated the clock immediately after the erase and it didn't seem to help. Maybe it needs a little cooling off period before recalibration as well? So mysterious! All that said, the Digispark is completely and totally non-compliant with the USB specification and can never be compliant. It's a bunch of hacks which work almost all of the time. I just try and make the software better at detecting when things go wrong and automatically recovering, since things are bound to go wrong from time to time with so many hacks. When I first heard of the digispark my response was "What? No, that's not possible. You must be wrong. It wouldn't be an attiny85 chip". And then I ended up writing the bootloader which i thought was impossible back then. Crazy!
Metametanote: Digispark wasn't going to use micronucleus when the kickstarter was made - micronucleus didn't exist till well after the kickstarter! They had a different bootloader I don't know much about, but they decided it was no good and poked me to make something a couple of weeks before it went to manufacture. I'm still amazed that micronucleus works as well as it does. Not many people seem to have trouble with it, but I continue to irrationally fear that one day all of a sudden all 40,000 digisparks ever made will stop working and it will all be my fault because I'm not a very good programmer. Heh.
<_<
>_>
