search

sleemanj / optiboot

Small and Fast Bootloader for Arduino and other Atmel AVR chips
66 stars 13 forks source link

How to program fuse not included in the menu options? #26

Closed gwideman closed 2 years ago

gwideman commented 2 years ago

On ATMega168PA, I would like to be able to program fuse CKOUT (Low byte, bit 6), in order to observe clock operation (ie: without sticking a scope on the XTAL pins and thereby loading them down.)

Is there a way to do that in conjunction with still using your convenient menu scheme and bootloader Hex files?

Thanks!

sleemanj commented 2 years ago

That is not currently supported, you'd need to do it with avrdude directly.

It probably could be made possible in the same was the mega8 constructs it's low_fuses https://github.com/sleemanj/optiboot/blob/master/dists/diy_atmega8_series/avr/boards.txt#L113 https://github.com/sleemanj/optiboot/blob/master/dists/diy_atmega8_series/avr/boards.txt#L159

so it would need modification to the low_fuses, all the speeds, all the advanced clocks, and adding a new menu option similar to how the CKOPT is handled by the mega8 https://github.com/sleemanj/optiboot/blob/master/dists/diy_atmega8_series/avr/boards.txt#L1309 https://github.com/sleemanj/optiboot/blob/master/dists/diy_atmega8_series/avr/boards.txt#L1365 https://github.com/sleemanj/optiboot/blob/master/dists/diy_atmega8_series/avr/boards.txt#L1410 https://github.com/sleemanj/optiboot/blob/1293cdaebe8e8ad63abbbe693ffb4b5839318437/dists/diy_atmega8_series/avr/boards.txt#L87

gwideman commented 2 years ago

OK, I won't lobby too hard for that option, because as you say, it should be feasible with avrdude directly.

So having set up the options using your menus, I could view the avrdude commands that the IDE runs, and then modify those to suit to run manually. Exploring the avrdude commands that the IDE issues, I found two anomalies:

  1. Bootloader programming proceeds by invoking two avrdude commands in sequence: first setting the fuses, and then a second run of avrdude to program the flash, for the bootloader per se.

So if the options command the first call to avrdude to set the fuses to a different clock type (for example), the chip might not be capable of responding to the second invocation of avrdude to program the bootloader. Also the output from avrdude even in the first command says it is erasing the chip. I am hoping this means just the fuses, so that a previously programmed bootloader would remain.

  1. A sample "Burn Bootloader" run after setting options with your menu results in failure of the first avrdude invocation during its verification steps. I'm not sure what to make of that. (The "failed" message appears a few lines before end of output from the command, suggesting avrdude isn't flushing its output quite right, resulting in out-of-sequence streams for STDOUT and STDERR.) Could it be that the verification of the efuse fails due to the reason mentioned in the WARNING of the second invocation: "invalid value for unused bits in fuse "efuse", should be set to 1 according to datasheet".

Here's the output of the sample run:

C:\Users\graham\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino17/bin/avrdude -CC:\Users\graham\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino17/etc/avrdude.conf -v -patmega168p -cstk500v1 -PCOM7 -b19200 -e -Ulock:w:0x3F:m -Uefuse:w:0x04:m -Uhfuse:w:0b11011111:m -Ulfuse:w:0xE0:m 

avrdude: Version 6.3-20190619
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "C:\Users\graham\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino17/etc/avrdude.conf"

         Using Port                    : COM7
         Using Programmer              : stk500v1
         Overriding Baud Rate          : 19200
         AVR Part                      : ATmega168P
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PC2
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65    20     4    0 no        512    4      0  3600  3600 0xff 0xff
           flash         65     6   128    0 yes     16384  128    128  4500  4500 0xff 0xff
           lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

         Programmer Type : STK500
         Description     : Atmel STK500 Version 1.x firmware
         Hardware Version: 2
         Firmware Version: 1.18
         Topcard         : Unknown
         Vtarget         : 0.0 V
         Varef           : 0.0 V
         Oscillator      : Off
         SCK period      : 0.1 us

avrdude: AVR device initialized and ready to accept instructions

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

avrdude: Device signature = 0x1e940b (probably m168p)
avrdude: erasing chip
avrdude: reading input file "0x3F"
avrdude: writing lock (1 bytes):

Writing | ################################################## | 100% 0.01s

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

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

avrdude: verifying ...
avrdude: 1 bytes of lock verified
avrdude: reading input file "0x04"
avrdude: writing efuse (1 bytes):

Writing |  ***failed;  
################################################## | 100% 0.06s

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

C:\Users\graham\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino17/bin/avrdude -CC:\Users\graham\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino17/etc/avrdude.conf -v -patmega168p -cstk500v1 -PCOM7 -b19200 -Uflash:w:C:\Users\graham\AppData\Local\Arduino15\packages\diy_atmega8_series\hardware\avr\2020.10.9/bootloaders/optiboot_atmega168p_16000000L_57600.hex:i -Ulock:w:0x3F:m 
Reading | ################################################## | 100% 0.01s

avrdude: verifying ...
avrdude: WARNING: invalid value for unused bits in fuse "efuse", should be set to 1 according to datasheet
This behaviour is deprecated and will result in an error in future version
You probably want to use 0xfc instead of 0x04 (double check with your datasheet first).
avrdude: 1 bytes of efuse verified
avrdude: reading input file "0b11011111"
avrdude: writing hfuse (1 bytes):

Writing | ################################################## | 100% 0.01s

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

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

avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: reading input file "0xE0"
avrdude: writing lfuse (1 bytes):

Writing | ################################################## | 100% 0.01s

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

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

avrdude: verifying ...
avrdude: 1 bytes of lfuse verified

avrdude done.  Thank you.

avrdude: Version 6.3-20190619
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "C:\Users\graham\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino17/etc/avrdude.conf"

         Using Port                    : COM7
         Using Programmer              : stk500v1
         Overriding Baud Rate          : 19200
         AVR Part                      : ATmega168P
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PC2
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65    20     4    0 no        512    4      0  3600  3600 0xff 0xff
           flash         65     6   128    0 yes     16384  128    128  4500  4500 0xff 0xff
           lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

         Programmer Type : STK500
         Description     : Atmel STK500 Version 1.x firmware
         Hardware Version: 2
         Firmware Version: 1.18
         Topcard         : Unknown
         Vtarget         : 0.0 V
         Varef           : 0.0 V
         Oscillator      : Off
         SCK period      : 0.1 us

avrdude: AVR device initialized and ready to accept instructions

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

avrdude: Device signature = 0x1e940b (probably m168p)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "C:\Users\graham\AppData\Local\Arduino15\packages\diy_atmega8_series\hardware\avr\2020.10.9/bootloaders/optiboot_atmega168p_16000000L_57600.hex"
avrdude: writing flash (16384 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 16384 bytes of flash written
avrdude: verifying flash memory against C:\Users\graham\AppData\Local\Arduino15\packages\diy_atmega8_series\hardware\avr\2020.10.9/bootloaders/optiboot_atmega168p_16000000L_57600.hex:
avrdude: load data flash data from input file C:\Users\graham\AppData\Local\Arduino15\packages\diy_atmega8_series\hardware\avr\2020.10.9/bootloaders/optiboot_atmega168p_16000000L_57600.hex:
avrdude: input file C:\Users\graham\AppData\Local\Arduino15\packages\diy_atmega8_series\hardware\avr\2020.10.9/bootloaders/optiboot_atmega168p_16000000L_57600.hex contains 16384 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 16384 bytes of flash verified
avrdude: reading input file "0x3F"
avrdude: writing lock (1 bytes):

Writing | ################################################## | 100% 0.01s

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

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

avrdude: verifying ...
avrdude: 1 bytes of lock verified

avrdude done.  Thank you.
sleemanj commented 2 years ago

Yes two steps, that is how the process works in Arduino (I don't off hand remember if that's a requirement of Arduino, or a requirement of AVR's themselves).

Erasing is erasing. Uploading USING the bootloader doesn't erase the bootloader because the bootloader doens't erase itself. Uploading via programmer erases the entire chip (you can not selectively erase). Installing a bootloader is uploading via programmer. Again this is how Arduino works. Since lock-bits could technically be wanted to be changed it has to be erased to do that anyway (for obvious reasons you literally can't unlock a chip without erasing it)

Yes certainly the two steps means the fuses could be changed and then the bootloader not be able to be uploaded because of that. Again, this is how Arduino works.

It's hard to tell what's going on in your output, looks like you have two processes running at once and the output is confused. The efuse is written as 0x04 because of the verifying issue, see "EXTENDED FUSE NOTES" in the boards.txt.

gwideman commented 2 years ago

Thanks for your reply, I appreciate your patience!

Erasure: I'm not sure we're on the same page. You say that "erasing is erasing... you cannot selectively erase". Yet based on there being two invocations of avrdude, both of which state they perform an erase, I infer that the flash has a separate erase than the fuses, because otherwise the second run of avrdude would undo the fuse settings of the first run.

(I do understand that you can't erase the "sketch area" separately from the bootloader area of flash, as they are really all the same area. But that's not the topic here.)

Confused output sequence

looks like you have two processes running at once and the output is confused

On re-examining the output, I now understand that there are 20 or 30 lines of output from the first avrdude command appearing after the second avrdude command is issued. What I posted is copied direct from the IDE console window. I tried this some more times, and the second command appears at different numbers of lines before the end of the first command's output. So I think this is a bug in the buffering of the IDE's console window. I have filed a bug report: Bug: IDE shows avrdude output out-of-order arduino/arduino-cli#1825

Error relevant to DIY optiboot That said, a point relevant to your optiboot scheme is this:

avrdude: verifying ...
avrdude: 1 bytes of lock verified
avrdude: reading input file "0x04"
avrdude: writing efuse (1 bytes):

Writing |  ***failed;  
################################################## | 100% 0.06s

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

avrdude: verifying ...
avrdude: WARNING: invalid value for unused bits in fuse "efuse", should be set to 1 according to datasheet
This behaviour is deprecated and will result in an error in future version
You probably want to use 0xfc instead of 0x04 (double check with your datasheet first).
avrdude: 1 bytes of efuse verified

That "***failed;" message looks a bit wonky, interposed between "Writing |" and the progress bar.

However, I looked at avrdude's source code and it's actually as-designed. update.c -> do_op() lines 295...

    if (!(flags & UF_NOWRITE)) {
      report_progress(0,1,"Writing");
      rc = avr_write(pgm, p, upd->memtype, size, (flags & UF_AUTO_ERASE) != 0);
      report_progress(1,1,NULL);
    }

and avr.c avr_write() lines 1012...

    if (do_write) {
      rc = avr_write_byte(pgm, p, m, i, data);
      if (rc) {
        avrdude_message(MSG_INFO, " ***failed;  ");
        avrdude_message(MSG_INFO, "\n");
        pgm->err_led(pgm, ON);
        werror = 1;
      }
    }

So the jumbled-seeming message is actually in the correct sequence as written in the code.

The avr_write_byte() function apparently failed trying to write 0x04. For stk500v1, avr_write_byte() calls avr_write_byte_default(), which has many subsidiary steps, many of which print messages, and those that don't, do return distinct error codes, but the calling function (avr_write() ) does not report them.

In a separate command line window, I re-ran the fuse-setting avr command line, but substituting in "-Uefuse:w:0xfc:m" (ie: 0xfc instead of 0x04), and that version of the command ran without error. (I ran the original command from the command line and it gave the original error. -- just to validate that it's not the separate command window that makes a difference.)

Bottom line, a command composed by your menu scheme failed while trying to write the efuse. So may be worth looking at?

sleemanj commented 2 years ago

Erase erases flash, lockbits, and optionally (by fuse specification) eeprom. Search the datasheet for "Chip Erase"

As per the comment in the boards.txt, the version of avrdude which was current at the time would not verify with FC and requried 04. That may have reversed now. I don't have a 168Px to test with.

gwideman commented 2 years ago

per the comment in the boards.txt,

I only just realized you're referring to your boards.txt file, not Arduino's. OK, so this is the salient note:

  # avrdude masks out some bits of the extended fuse on read, which would result 
  # in verification error of the extended fuse if you give it an unmasked value

Apparently that's not the case any more (avrdude Version 6.3-20190619). Here are sample runs with 168pa (somewhat overlapping with previous messages):

Using 0x04

avrdude: reading input file "0x04"
avrdude: writing efuse (1 bytes):

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

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

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

avrdude: verifying ...
avrdude: WARNING: invalid value for unused bits in fuse "efuse", should be set to 1 according to datasheet
This behaviour is deprecated and will result in an error in future version
You probably want to use 0xfc instead of 0x04 (double check with your datasheet first).
avrdude: 1 bytes of efuse verified
a

Using 0xfx:

avrdude: reading input file "0xfc"
avrdude: writing efuse (1 bytes):

Writing | ################################################## | 100% 0.01s

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

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

avrdude: verifying ...
avrdude: 1 bytes of efuse verified

So I guess, though the message says "Failed", avrdude doesn't yet regard it as a show-stopping error, but plans to do so in future.

sleemanj commented 2 years ago

Duplicate comment deleted.

sleemanj commented 2 years ago

Release tonight (2022.3.12) shoudl resolve this.

New menu in Tools "Override CKOUT" where you can choose to enable this (and you'll have to burn bootloader of course to set the fuse).

Also ability to explicitly set the Compilter Target

Also have changed fuse specification so that the verification should work

lu30