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

Submitted by:  None
Submitted on:  Mon 18 Dec 2017 10:22:42 AM UTC  
 
Category: NoneSeverity: 3 - Normal
Priority: 5 - NormalItem Group: None
Status: NonePrivacy: Public
Assigned to: NoneOriginator Name: James Collier
Originator Email: -unavailable-Open/Closed: Open
Release: 6.0.1Programmer 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>
Project 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>
Project 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

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    No Changes Have Been Made to This Item

    Back to the top


    Powered by Savane 3.1-cleanup1