ATtiny2313A does not run after RSTDISBL fuse was programmed.

[DavidGriffith]

Created by: chenz

I'm having trouble programming an ATtiny2313A with the RSTDISBL fuse enabled. It works when using the Windows software under Wine. Here is the config (SPIEN off, RSTDISBL on):

fuses_lo = 0x0064
fuses_hi = 0x00fe
fuses_ext = 0x00ff
lock_byte = 0x00ff

After the fuse is programmed, only 0xff is read from the uC, and the part can no longer be identified. The same happens with the Windows software. The difference is that the uC actually runs when using the Windows software. With this software, it looks like it stays in reset...

I can reset the fuse (ie fuses_hi = 0x00df) just fine and the uC will then again respond normally.

[DavidGriffith]

Created by: chenz

I have now gotten it to work somehow. Starting with the chip not working:

minipro -p ATTINY2313A -w code.bin -y
Found Minipro TL866CS v03.2.80
WARNING: Chip ID mismatch: expected 0x1e910a, got 0xffffff
Writing Code... OK
Reading Code... OK
Verification OK

Note that at the beginning, the chip id cannot be read, but at the end, verification succeeds - so no longer just 0xff is read. Also the fuses are now reset to a default setting (this really confuses me - what causes this? the chip? the firmware?) and the chip id can be read again:

minipro -p ATTINY2313A -r tmp.bin
Found Minipro TL866CS v03.2.80
Chip ID OK: 0x1e910a
Reading Code... OK
Reading Data... OK
Reading fuses... OK

Fuses as read back:

fuses_lo = 0x0062
fuses_hi = 0x00df
fuses_ext = 0x00ff
lock_byte = 0x00ff

Now I set the fuses again, this time using -e to make sure the code is not touched:

minipro -p ATTINY2313A -e -c config -w my-fuses.conf 
Found Minipro TL866CS v03.2.80
Chip ID OK: 0x1e910a 
Writing fuses... OK

After this, the chip is back to reading only 0xff - but it runs in circuit!

[DavidGriffith]

Created by: elosha

@chenz: You disabled the SPI interface as well as the reset pin. The behaviour to read only 0xFF = nothing via ISP seems correct to me.

Atmel ATtiny2313A datasheet: "Programming this fuse bit will change the functionality of the RESET pin and render further programming via the serial interface impossible. The fuse bit can be unprogrammed using the parallel programming algorithm (see page 184)."

This happened when you wondered why the MCU can be written and read back afterwards, because the MiniPro TL866 – as high voltage programmer – can still talk to the MCU by parallel programming algorithm. It seems, the parallel mode is only used for writing to the MCU, but theoretically could also be used for reading. Then you would have been able to read it.

To break it down:

1. Where do the changed fuse bytes come from? Default would be 0x64 0xDF 0xFF
2. Why didn't the MCU start to run in the first time? Corrupted fuses?
3. Should minipro read the ATtiny in high voltage mode? Offer or default?

[DavidGriffith]

Created by: chenz

ISP being used to read out the chip would explain the read issues - I would have assumed parallel mode to be used - that is kind of the whole point of me using the minipro in this application in the first place.