Failed to chip erase using key

[ygoe]

I'm just starting with the ATtiny 1-series and tried my first program today. I'm using an ATtiny 1614 that I just unpacked and soldered to an adapter PCB. The USB-serial-adapter is an FT232RL that you get from online sellers. It shows up in Windows 10 as COM6. I've set things up as explained and tried to upload the compiled executable. I'm using Atmel Studio 7 and have written a simple program that should enable an output pin. I've connected an LED through a resistor to it to see the result. The integration in Atmel Studio didn't work. First it actually ran pyupdi and told me I missed to install the serial module. I installed that and Atmel Studio would from then on never try to run pyupdi again. So I'm doing this on the command line now.

After installing more dependencies, the output now looks like this:

>python C:\Source\Mikrocontroller\pyupdi\pyupdi.py -d tiny1614 -c COM6 -f ATTinyTest1.hex
Device is locked. Performing unlock with chip erase.
Traceback (most recent call last):
  File "C:\Source\Mikrocontroller\pyupdi\pyupdi.py", line 98, in _main
    nvm.enter_progmode()
  File "C:\Source\Mikrocontroller\pyupdi\updi\nvm.py", line 34, in enter_progmode
    if self.application.enter_progmode():
  File "C:\Source\Mikrocontroller\pyupdi\updi\application.py", line 129, in enter_progmode
    raise Exception("Failed to enter NVM programming mode")
Exception: Failed to enter NVM programming mode

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Source\Mikrocontroller\pyupdi\pyupdi.py", line 178, in <module>
    _main()
  File "C:\Source\Mikrocontroller\pyupdi\pyupdi.py", line 101, in _main
    nvm.unlock_device()
  File "C:\Source\Mikrocontroller\pyupdi\updi\nvm.py", line 54, in unlock_device
    self.application.unlock()
  File "C:\Source\Mikrocontroller\pyupdi\updi\application.py", line 89, in unlock
    raise Exception("Failed to chip erase using key")
Exception: Failed to chip erase using key

What does that mean? What should I do next?

[ygoe]

Update: I managed to program the chip now. I first tried it with 3.3 V from the USB-serial adapter. After changing this to 5 V it worked. But only once. The second time I got the same error message. After unplugging the thing and plugging it back in a bit later, it worked again. After trying it more often, it also works at 3.3 V.

Is this normal that the chip can only be programmed once after powering it?

[ygoe]

Mostly works now on another computer. Not sure what happened before. Maybe it was the starting through Atmel Studio which I haven't tried on the other computer. Sometimes the transfer still fails, but then unplugging and reconnecting (and thereby resetting the ATtiny) helps.

[PetteriAimonen]

For me I got this same error message when the USB-serial adapter (CP2102 based) was connected to an USB hub, but programming worked when I connected to same computer directly.

[ygoe]

A USB hub doesn't seem to have that effect for me. On my first computer, my desktop PC, the USB serial adapter was connected directly to a mainboard backside USB port (with a regular ~1.5m cable). On the second one, a Surface Pro, there is only one USB adapter and I also need it for the RS-485 adapter that I use for my application. Both are connected via a passive USB 3 hub and it mostly works fine. I can even keep both devices fully connected. I just shouldn't lean over my cables while programming. It's more reliable when I move back a bit and keep still. If the ATtiny is powered from a lab power supply or connected to the oscilloscope, programming often fails. So no other connections (or ground) should be present. (The Surface power supply has no ground connection.)

But still, programming fails forever after it has aborted once and as long as I don't disconnect the MCU power before trying again. Somehow the chip seems to be "locked" temporarily after a failed programming.