AVR Freaks

Yup. Not possible to unlock by programming. A chip erase is the only way. Otherwise it wouldn't be a lock, would it ;-)

In fact, some bootloaders don't even correctly report lock bits, fuses, or eeprom.

Also, if you go back to the op...

This is what you have in your OP:

avrdude -c arduino -b 19600 -p m32u4 -P COM4 -U lock:w:0xef:m -v

How exactly are you expecting to change the lock bits on an ATtiny104 with that command?  As you've been told several times now, that command talks to the 32U4, and uses its bootloader to do it.

EDIT: sp

I think the lock bits in an Xmega can be changed to a more secure setting by software.  So I think a bootloader could do that.

Megas and (some) Tinies can do that, too.  A bootloader could as well, but it has to be >>written<< to do so.  The most common (arguably) bootloader, Optiboot, does not.  The OP is using an Arduino Micro, which ships with the Diskloader bootloader by default.  That bootloader implements a subset of stk500v1, and supports read/write to flash only (like Optiboot).  Reads/writes of any other NVM will (likely) silently be treated as flash.

I don't think the OP should lock anything unless he has the ability to unlock.

Agreed, but the OP hasn't figured out the difference between an m32U4 and a t104 yet.  Once that's sorted, and the 32U4 is playing the part of an AVRISP, s/he'll be able to lock/erase the t104 or any other target as needed.  Locking the 32U4 via its own as-shipped bootloader will never work.

I don't know how his AVRISP connects to the chip.

S/he doesn't have one, only an Arudino Micro with a sketch to turn it into an AVRISP, much like ArduinoISP.ino turns an UNO or other Arduino with an 328P into an ISP programmer.

This is the trouble with random internet tutorials.  You never know if they are complete or even correct.

When I tried to program the lock bits according to Section 5, #6 of the tutorial

OK:

５．Burn the DFU-loader and Start

1. Do the work without connecting the USB connector to Arduino Leonardo / Micro.
2. Connect the AVR-Programmer to Arduino Leonardo / Micro and start the AVR-Programmer software.
3. Erase flash memory of Arduino Leonardo / Micro.
4. Set Fuse-Bits as below.
   lowFuse  0xFF     , highFuse 0xD9      ,extendedFuse 0xC3
   Caution: When if you incorrect the Fuse-Bits settings, your Leonardo/Micro become to brick.
5. Burn the ATMega32U4-usbdevice_dfu-1_0_0.hex (include in megaUSB_DFU_Bootloaders_2 folder ) to your Leonardo/Micro.
6. Set Lock-Bits 0xEF
7. Detach AVR-Programmer.
8. From here, connect a USB connector to your Leonardo / Micro and connect it to a PC.
9. The USB device “ATMEL ATm32U4DFU” appears on your PC.
10. If the device driver is required, specify C: \ Program Files \ Atmel \ Flip 3.4.7 \ usb \ .  and install the driver.

But then you try:

C:\Users\RJ>avrdude -c arduino -b 19600 -p m32u4 -P COM4 -U lock:w:0xef:m -v

I've lost track of how many times you've been told you can't set the m32u4's lock bits by talking to its bootloader.

How did you arrive at the above command?  For that matter, how did you program the .hex file in step 5?

I have a Mega 2560 hooked up to it via ICSP running the Arduino as ISP sketch. Now I am just using avrdude to carry out commands. Again, sorry, I didn't think this was relevant.

Were' now at fifteen posts in this thread, and we're only now learning that you're using another Arduino as a programmer.  That is fairly important information.

The -c option to avrdude tells it what kind of programmer it will be talking to.  The -c arduino programmer option tells it that it will be talking to an Optiboot-compatible bootloader.  As such, if the device you have connected as the programmer >>has<< such a bootloader, it will be the thing responding to avrdude.  So, given that you also passed the -p part option as m32u4, >>and<< given that the bootloader didn't complain about an incorrect signature, it seems clear that you are connected to the Arduino Micro and its m32u4, and that you are talking to it via its bootloader.  This will not accomplish your goal.  Specifically, you are not talking to your mega 2560 as you should be.  Further, it suggests that you've ignored step #1:

1. Do the work without connecting the USB connector to Arduino Leonardo / Micro.

Otherwise, you would never be able to get a response from the m32u4's bootloader.

If you need help here, you need to be >>very<< clear about >>every<< step you are taking.  Don't assume that we can see you screen.  We can't.  Describe in detail all of the steps you have taken, including all physical steps such as what you've connected to what and how, along with all command lines issued and terminal output observed at each step.  What you have shown us so far is not sufficient.  The only conclusions possible are what you have already been told.

Perhaps it is time to read this:

https://www.avrfreaks.net/forum/newbie-start-here

Again, no.  The -c arduino option to avrdude directs it to speak to a bootloader on the connected port.

You've put ArduinoISP.ino sketch onto your Arduino Mega 2560, as per:

３．Prepare these

1. Arduino Leonardo Rev.3 / Micro or clones.
2. Windows PC (It can also be Windows running on Mac / Linux virtual machine)
3. another AVR-Programmer or Arduino UNO (ArduinoISP sketch running)

...?

You've connected the Mega 2560 to your computer with a USB cable?

You've connected the appropriate pins on the Arduino Mega 2560 to the ISP pins of the Arduino Micro?:

Mega     => Micro

-----------------

MISO(50) => MISO

MOSI(51) => MOSI

SCK (52) => SCK

SS  (53) => RESET

VCC      => VCC

GND      => GND

...?

Then the command you should be issuing is:

$ avrdude -c stk500v1 -b 19200 -p m32u4 -P your-mega's-com-port -U whatever-you-want-to-write

and it worked exactly the same

Nope.

First you got:

Command: C:\Users\RJ>avrdude -c arduino -b 19600 -p m32u4 -P COM4 -U lock:w:0xef:m -v

Writing |                                                    | 0% 0.00s ***failed;
Writing | ################################################## | 100% 0.11s

avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0xef:
avrdude: load data lock data from input file 0xef:
avrdude: input file 0xef contains 1 bytes
avrdude: reading on-chip lock data:

Reading | ################################################## | 100% 0.02s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
         0xef != 0x20
avrdude: verification error; content mismatch

Then you got:

C:\Users\RJ>avrdude -c stk500v1 -b 19200 -p m32u4 -P COM4 -U lock:w:0xEF:m

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.03s

avrdude: Device signature = 0x1e9587
avrdude: reading input file "0xEF"
avrdude: writing lock (1 bytes):

Writing |                                                    | 0% 0.00s ***failed;
Writing | ################################################## | 100% 0.11s

avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0xEF:
avrdude: load data lock data from input file 0xEF:
avrdude: input file 0xEF contains 1 bytes
avrdude: reading on-chip lock data:

Reading | ################################################## | 100% 0.01s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
         0xef != 0x2f
avrdude: verification error; content mismatch

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

Aside from the fact that in your OP you failed to include the entire output of avrdude (why exactly?), the sessions proceed the same, >>except<< the reported mismatched value for the lock bits.  That's rather important.

In your OP, it was 0x20.  In your last post, it was 0x2F.  This suggests to me that you are at least now actually talking to the mega's ArduinoISP sketch (rather than to its bootloader), and that the sketch is properly addressing the target m32u4.

Looks like the avrdude config file you're using reports the two unused lock bits (bits 6 and 7) as '0', rather than as '1', as is the norm:

That is not terribly unusual.  The avrdude config file has a few oddities in it.  This is probably one of them.

As such, your '0xEF' lock byte should probably be specified as 0x2F instead.  Note that this is the reported mismatch value, suggesting that the BLB11 bit has been successfully programmed, setting up mode 4 (whoops) 2:

... as intended.