bugAVR Downloader/UploaDEr - Bugs: bug #52687, avrdude eeprom uploader always...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #52687: avrdude eeprom uploader always uploads 0xff if line terminator is LF not CRLF

Submitter:  None
Submitted:  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:  -email is unavailable- Open/Closed:  Open
Release:  6.0.1 Programmer hardware:  USBTiny
Device type:  atmaga328p

Sat 30 Dec 2017 07:23:47 AM UTC, comment #3: 

The question is not about removing whitespace but reimplementing
fgets() rather than using the system/library version.

 Joerg Wunsch <joerg_wunsch>
Group administrator
Sat 30 Dec 2017 01:21:32 AM UTC, comment #2: 

Windows and line termination characters may or may not be the problem, but removal of white space from the end of a line is not likely to have any noticeable impact on performance.

 Ryniker <ryniker>
Fri 29 Dec 2017 11:29:37 PM UTC, comment #1: 

I'd have replied that Intel Hex files are by definition to be
terminated with CR-LF, but it seems Intel indeed never
specified this.

The behaviour you are mentioning does by no means to be
intended by the way the code is written.  Curious, are you
working on Windows?  The code uses fgets() to read the file
line by line, but on Windows, that probably requires CR-LF
line termination.  (On Unix-like systems, it just needs LF,
and any possible CR is later ignored.)  Replacing fgets()
is, unfortunately, quite cumbersome as it is very likely that
any manual reimplementation is going to be slower than the
library-provided fgets().

 Joerg Wunsch <joerg_wunsch>
Group administrator
Mon 18 Dec 2017 10:22:42 AM UTC, original submission:  

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.


Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by ryniker (Posted a comment)
  • -email is unavailable- added by joerg_wunsch (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)

    •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    No changes have been made to this item

    Back to the top

    Copyright © 2024 Free Software Foundation, Inc.
    Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
    The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team.
    Page source code

    Powered by Savane 3.14-f13d.
    Corresponding source code