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
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       No canned response available

 

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

 

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

Attach Files:
   
   
Comment:
   

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.

    Only logged-in users can vote.

     

     

     

     

    No changes have been made to this item

    Back to the top


    Powered by Savane 3.9