xyphro / UsbGpib

Versatile, cheap and portable USB to GPIB converter (USBTMC class based)
MIT License
277 stars 50 forks source link

Warning Messages Programming the Firmware #50

Closed dazz100 closed 8 months ago

dazz100 commented 9 months ago

Hi I have hit an issue with warning messages from avrdude while loading the firmware. If I am seeing this issue, it is likely others will.

I have successfully upgraded the firmware on my cheap Chinese USBasp programmer. It is still working. This fixed the 'cannot set sck period' issue, unlocked slow programming mode and sped up programming time. There are a number of tutorials on YouTube, but I used this one. https://www.youtube.com/watch?v=JHBodye_EWI

To program the usb-gpib adapter firmware, I use the command: ..\avrdude -c usbasp -p m32u4 -e -Ulock:w:0x3F:m -Uefuse:w:0xcb:m -Uhfuse:w:0xd8:m -Ulfuse:w:0xff:m -U flash:w:TestAndMeasurement.hex -U flash:w:BootLoader.hex

This single command programs the usb-gpib firmware. Just save the two hex files in a sub-directory (named anything) of "avrdude", and run the avrdude command while in that directory.

When I do that I get a number of warnings about unused bits as seen below:

avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9587 (probably m32u4)
avrdude: erasing chip
avrdude: reading input file 0x3F for lock
         with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte lock ...
 ***failed;
avrdude: 1 byte of lock written
avrdude: verifying lock memory against 0x3F
avrdude warning: ignoring mismatch in unused bits of lock
        (device 0xff != input 0x3f); to prevent this warning set
        unused bits to 1 when writing (double check with datasheet)
avrdude: 1 byte of lock verified
avrdude: reading input file 0xcb for efuse
         with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte efuse ...
 ***failed;
avrdude: 1 byte of efuse written
avrdude: verifying efuse memory against 0xcb
avrdude warning: ignoring mismatch in unused bits of efuse
        (device 0xfb != input 0xcb); to prevent this warning set
        unused bits to 1 when writing (double check with datasheet)
avrdude: 1 byte of efuse verified
avrdude: reading input file 0xd8 for hfuse
         with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte hfuse ...
avrdude: 1 byte of hfuse written
avrdude: verifying hfuse memory against 0xd8
avrdude: 1 byte of hfuse verified
avrdude: reading input file 0xff for lfuse
         with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte lfuse ...
avrdude: 1 byte of lfuse written
avrdude: verifying lfuse memory against 0xff
avrdude: 1 byte of lfuse verified
avrdude: reading input file TestAndMeasurement.hex for flash
         with 13568 bytes in 1 section within [0, 0x34ff]
         using 106 pages and 0 pad bytes
avrdude: writing 13568 bytes flash ...

Writing | ################################################## | 100% 6.68 s

avrdude: 13568 bytes of flash written
avrdude: verifying flash memory against TestAndMeasurement.hex

Reading | ################################################## | 100% 3.53 s

avrdude: 13568 bytes of flash verified
avrdude: reading input file BootLoader.hex for flash
         with 5724 bytes in 5 sections within [0x6000, 0x7fff]
         using 46 pages and 164 pad bytes
avrdude: writing 5724 bytes flash ...

Writing | ################################################## | 100% 0.15 s

avrdude: 5724 bytes of flash written
avrdude: verifying flash memory against BootLoader.hex

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

avrdude: 5724 bytes of flash verified

avrdude done.  Thank you.

The bits are unused and these are only warnings, so there should be no harm. So part of the aim of this issue is to show:

  1. the single command to fully program the adapter and,
  2. the output for a successful programming of the firmware.

If the warnings are acceptable, then the only action is to close this issue.

xyphro commented 9 months ago

Hi dazz100!

Indeed, somehow unused bits sneaked into the avrdude command description of the readme.md. It won't hurt, but irritates.

Will address this in a readme.md update in next update round, let's keep this open until I addressed it.

Thanks for sharing the single update version!

Best regards,

Kai

xyphro commented 8 months ago

Hi Dazz100,

will push in a few minutes a new update which includes this. Thanks for your input! I also updated the fuses, so that no unused bits are used.

Best regards,

Kai

dazz100 commented 8 months ago

Hi Just downloaded and programmed the latest UsbGpib firmware. My usbasp programmer has the latest firmware installed. The following is the output messaging of a successful firmware install:

`G:\Programs\avrdude-v7.1\binaries>..\avrdude -c usbasp -p m32u4 -e -Ulock:w:0x3F:m -Uefuse:w:0xcb:m -Uhfuse:w:0xd8:m -Ulfuse:w:0xff:m -U flash:w:TestAndMeasurement.bin -U flash:w:BootLoader.hex

avrdude: AVR device initialized and ready to accept instructions avrdude: device signature = 0x1e9587 (probably m32u4) avrdude: erasing chip avrdude: reading input file 0x3F for lock with 1 byte in 1 section within [0, 0] avrdude: writing 1 byte lock ... failed; avrdude: 1 byte of lock written avrdude: verifying lock memory against 0x3F avrdude warning: ignoring mismatch in unused bits of lock (device 0xff != input 0x3f); to prevent this warning set unused bits to 1 when writing (double check with datasheet) avrdude: 1 byte of lock verified avrdude: reading input file 0xcb for efuse with 1 byte in 1 section within [0, 0] avrdude: writing 1 byte efuse ... failed; avrdude: 1 byte of efuse written avrdude: verifying efuse memory against 0xcb avrdude warning: ignoring mismatch in unused bits of efuse (device 0xfb != input 0xcb); to prevent this warning set unused bits to 1 when writing (double check with datasheet) avrdude: 1 byte of efuse verified avrdude: reading input file 0xd8 for hfuse with 1 byte in 1 section within [0, 0] avrdude: writing 1 byte hfuse ... avrdude: 1 byte of hfuse written avrdude: verifying hfuse memory against 0xd8 avrdude: 1 byte of hfuse verified avrdude: reading input file 0xff for lfuse with 1 byte in 1 section within [0, 0] avrdude: writing 1 byte lfuse ... avrdude: 1 byte of lfuse written avrdude: verifying lfuse memory against 0xff avrdude: 1 byte of lfuse verified avrdude: reading input file TestAndMeasurement.bin for flash with 13662 bytes in 1 section within [0, 0x355d] using 107 pages and 34 pad bytes avrdude: writing 13662 bytes flash ...

Writing | ################################################## | 100% 6.79 s

avrdude: 13662 bytes of flash written avrdude: verifying flash memory against TestAndMeasurement.bin

Reading | ################################################## | 100% 3.54 s

avrdude: 13662 bytes of flash verified avrdude: reading input file BootLoader.hex for flash with 5724 bytes in 5 sections within [0x6000, 0x7fff] using 46 pages and 164 pad bytes avrdude: writing 5724 bytes flash ...

Writing | ################################################## | 100% 0.13 s

avrdude: 5724 bytes of flash written avrdude: verifying flash memory against BootLoader.hex

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

avrdude: 5724 bytes of flash verified

avrdude done. Thank you. ` It shows the unused fuse bits issue is still alive. I understand warnings do not adversely affect anything except user confidence.
I am not sure about the effects of the failed lock byte write.