avrdude won't program certain lock bits

Go To Last Post
21 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am following a tutorial for making my Arduino Micro recognizable as an AVRISP-mkII. I already followed the tutorial once and got it to work as described; however, today I tried to use my micro with Atmel Studio and it would not work like before so I decided to re-do the tutorial so I could get my micro working again. I re-uploaded the Arduino bootloader and started from scratch. When I tried to program the lock bits according to Section 5, #6 of the tutorial, avrdude would not program the bits correctly. I got this error:

 

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

 

Why won't it program 0xEF? I have tried other lock bits and it works fine, but it won't do e. The weirdest part to me is that I already got it to work once, and I don't think anything has changed since then. Thanks!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You seem to be unlocking some locks.  I think the only way to do that is by doing a chip erase.

 

That may explain it, but I don't know.   I've never changed the locks.

 

If 0x20 is the current lock settings, doesn't that mean all locks except one are locked? 
 

Last Edited: Mon. Sep 18, 2017 - 02:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And besides locking/unlocking, you can't program the lock bits through the bootloader anyway.

Stefan Ernst

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't have a 32U4 datasheet to hand but also note that in some AVR fuse/lock bytes not all bits are used. So the bits that are not used may be set/reported as either 0 or 1. So when verifying "part written bytes" avrdude will often report an error where there is none simply because of a 1/0 mismatch in the unused bit positions.

 

(but that's not the main issue here - others have already told you what the problem is).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joeymorin wrote:
A chip erase is the only way.

 

I have tried using -e to erase, writing the hex, then writing the lock bits, but it still doesn't let me change the lock bits. I found out I can get it to work without the correct lock bits, is there any downside to doing this? I just want to use it with Atmel Studio to program my ATtiny104.

Last Edited: Tue. Sep 19, 2017 - 01:49 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Did you miss the part where we said you can't change lock bits from a bootloader?
You showed us an avrdude command for an ATmega32U4. Why are you now asking about an Ttiny 104?

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joeymorin wrote:
Did you miss the part where we said you can't change lock bits from a bootloader? You showed us an avrdude command for an ATmega32U4. Why are you now asking about an Ttiny 104?

 

I have gotten it to program other lock bits, is there something happening that I don't know about? As far as I can tell, I can make certain combinations work, but as I stated in the original post, it won't allow any Es. Is this because that accesses something I should not be allowed to access? All I know is that it will program some bits.

 

Also, if you go back to the op, I included the tutorial whose purpose is making an Arduino Micro recognizable as an AVRISP-mkII to program over TPI. Therefore, I think it follows that programming the Tiny104 is my end goal in this. So, my question is: Will the lock bit impede my ability to do program my Tiny or can I just ignore the lock bit part of the tutorial.

Last Edited: Tue. Sep 19, 2017 - 04:28 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Don't lock anything.  If you lock the application flash for writing, you won't be able to write to the application flash.

 

I am not familiar with the AVRISP.

 

I think you need to use PDI or JTAG to do a chip erase.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Tue. Sep 19, 2017 - 09:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

 

I don't think the OP should lock anything unless he has the ability to unlock.  Unlocking requires the chip erase command, which I think requires PDI or JTAG.

 

I don't know how his AVRISP connects to the chip.  If it connects via PDI or JTAG then in theory it could do a chip erase.

 

Last Edited: Tue. Sep 19, 2017 - 12:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joeymorin wrote:
How exactly are you expecting to change the lock bits on an ATtiny104 with that command

 

I'm not, if you had looked at the step I am referencing in the tutorial, I am on the part where I convert my Micro into a programmer. As I stated, the Tiny is the end goal, I am only asking if this step involving lock bits and the Micro even relates to my end goal. Also, I am sorry I didn't include how I was actually programming the Micro. 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.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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:

5.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:

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

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joeymorin wrote:
Further, it suggests that you've ignored step #1: Do the work without connecting the USB connector to Arduino Leonardo / Micro.

 

I understand what you are saying there, but I am doing all the programming through the Mega. I am able to to simply write the flash for 32u4 as shown above. I am sure I can do this because I can burn the Arduino bootloader on to the Micro through the Arduino IDE without a problem with my Mega in the current configuration. Therefore, as far as I can tell, when running the ISP sketch, my mega merely transmits the avrdude commands to the micro where it is acted upon whilst never affecting the mega. To make everything about my setup clear, I have my usb from my computer to my mega, and the individual ICSP pins on the mega connected to the ICSP header on my Micro.

 

With this setup, I can write memory, change fuse bits, and except for the above-described cases, write lock bits. As for the commands, I just modify the command I gave you for the given task, i.e:

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

or

C:\Users\RJ>avrdude -c arduino -b 19600 -p m32u4 -P COM4 -U lfuse:w:0xff:m -U hfuse:w:0xd9:m -U efuse:w:0xc3:m

or

C:\Users\RJ>avrdude -c arduino -b 19600 -p m32u4 -P COM4 -U flash:w:ATMega32U4-usbdevice_dfu-1_0_0.hex:a (this one is from memory, I don't have it up)

 

Again, all of these work, except for the lock bit problem.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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:

3.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

 

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Thu. Sep 21, 2017 - 04:45 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, I finally was able to get back to this. Yes, all the connections are the same except the rest pin which i changed to 30 and redefined in the program. I repeated the process with the new programmer and baudrate you described and it worked exactly the same. Here is the lock bit command I used:

 

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Tue. Sep 26, 2017 - 03:51 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joeymorin wrote:
Aside from the fact that in your OP you failed to include the entire output of avrdude (why exactly?)

 

Sorry, it was the same as it is this time (apart from the 0x2f obviously), and it didn't seem to say anything other than to confirm that the fuses were alright. I tried to include only what I thought was relevant (leading to many of the misunderstandings thus far.)

 

So, are you saying that it is setting the lock bit correctly and then, according to the lock bit, not allowing me to read it as described in BLB1 mode 4?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So, are you saying that it is setting the lock bit correctly and then, according to the lock bit, not allowing me to read it as described in BLB1 mode 4?

Sorry, that was a typo.  It is setting BLB1 mode 2, as shown by the yellow highlighted line in the screenshot I inlined into my last post.  I assume this is what the authors of the tutorial intend.  I have not perused the tutorial.  I can't imagine why they were advising you to set the lock bits to 0xEF, except that perhaps >>their<< version of the avrdude config file always reports bit 7 and '0' and bit 6 as '1' (again, not unheard of).  That's the only thing (I can think of) which would explain it.  In any event, your version clearly reports the both of the unused bits (6 and 7) as '0', so you must write them as '0' as well.  As such, 0xEF won't do.  We 'and' that with 0x3F to get 0x2F.  That's what you should write:

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

This should return with no mismatch and no errors.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]