avrdude-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[avrdude-dev] [bug #52687] avrdude eeprom uploader always uploads 0xff i


From: anonymous
Subject: [avrdude-dev] [bug #52687] avrdude eeprom uploader always uploads 0xff if line terminator is LF not CRLF
Date: Mon, 18 Dec 2017 05:22:43 -0500 (EST)
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/601.7.7 (KHTML, like Gecko) Version/9.1.2 Safari/601.7.7

URL:
  <http://savannah.nongnu.org/bugs/?52687>

                 Summary: avrdude eeprom uploader always uploads 0xff if line
terminator is LF not CRLF
                 Project: AVR Downloader/UploaDEr
            Submitted by: None
            Submitted on: Mon 18 Dec 2017 10:22:42 AM UTC
                Category: None
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
         Originator Name: James Collier
        Originator Email: address@hidden
             Open/Closed: Open
                 Release: 6.0.1
         Discussion Lock: Any
     Programmer hardware: USBTiny
             Device type: atmaga328p

    _______________________________________________________

Details:

It is useful to create eeprom .hex files from a program rather than from
avr-gcc, for instance in a production environment to set calibration constants
or a unique ID.

Uploading the resulting .hex file - in the correct form - using
>avrdude -p atmega328p -c -usbtiny -U eprom:w:myfile.hex
works fine: Writing and Reading  get the progress lines of # characters, then
the message
avrdude: verifying...
avrdude: 80 bytes of eeprom verified
etc.

BUT it loads every byte as 0xff if the .hex file has  \n line terminators. If
the hex file has \r\n terminators avrdude loads the correct data. There is no
difference in the messages from avrdude in either case.

I consider this a bug as (a) it's poor practice to make parsers unnessarily
strict, and (b) apparent success should not be reported when the operation
has, in fact, failed.






    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?52687>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]