bugAVR C Runtime Library - Bugs: bug #21410, Incorrect use of 16-bit eeprom...

 
 

bug #21410: Incorrect use of 16-bit eeprom addresses in devices with 8-Bit address registers

Submitted by:  Robert von Knobloch <robertvknobloch>
Submitted on:  Wed 24 Oct 2007 07:53:24 AM UTC  
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  libc code
Status:  Fixed Assigned to:  Dmitry Xmelkov <dmix>
Percent Complete:  100% Open/Closed:  Closed
Release:  None Fixed Release:  None

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Sat 08 Mar 2008 10:49:11 PM UTC, comment #6: 

Fixed in CVS HEAD and 1_6 branches.

Dmitry Xmelkov <dmix>
Project AdministratorIn charge of this item.
Sat 08 Mar 2008 02:21:24 PM UTC, comment #5: 

Changing owner to Dmitry.

Eric Weddington <arcanum>
Project Administrator
Tue 18 Dec 2007 10:48:57 PM UTC, comment #4: 

Deferred until 1.6.1.

Eric Weddington <arcanum>
Project Administrator
Tue 30 Oct 2007 12:43:45 PM UTC, comment #3: 

This can be fixed by reimplementing the EEPROM API via inline assembly macros. This will also potentially fix GCC bug #31644. I am currently working on such an implementation, so I'll take the bug.

Eric Weddington <arcanum>
Project Administrator
Wed 24 Oct 2007 10:56:00 AM UTC, comment #2: 

> If we skip this then we might be ok, if the eeprom.S
> file is build per device not per architecture.


Unfortunately, it actually is per architecture, not per
device.  That's the reason why it is compiled into two
different object files (for two different EEPROM base
addresses).

The only way I'm seeing is to compile it into four different
object files (base address vs. 8- or 16-bit addressing), and
extend the macro wrapper logic in <avr/eeprom.h>.

Joerg Wunsch <joerg_wunsch>
Project Administrator
Wed 24 Oct 2007 10:09:42 AM UTC, comment #1: 

I thinks the current file is capable of handling this.
But it always undefs EEARH to redefine it as EERAL+1.
If we skip this then we might be ok, if the eeprom.S file is build per device not per architecture. Which must be the case otherwise the whole setup can't work.

Another option would be to only use EEARH if E2END is larger then 0xFF. So instead of undef and def EEARH and doign a check on #ifdef EEARH we could do a #if E2END > 0xFF.

Just my 2 cents

Wouter <wutje>
Wed 24 Oct 2007 07:53:24 AM UTC, original submission:  

The library functions, defined in avr-libc-1.4.6/libc/misc/eeprom.S"
always write a 16-Bit address to the EEAR register. This is expressly forbidden in the Tiny13 datasheet and appears to cause faulty reading of the eeprom data under some circumstances.

Reference:
Tiny 13 datasheet on page 158, note 1: "Reserved I/O memory
addresses should never be written".
The same appears for the 8515 and 2313 (these are expressly mentioned in 'eeprom.S').

My proposal is to modify eeprom.S to write 16 bit addresses where the ioxxyy.h file defines EEARH and 8 bit to all others (seems OK for newer devices, I don't have experience of the older parts).

Robert von Knobloch <robertvknobloch>

 

(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 dmix (Posted a comment)
  • -email is unavailable- added by arcanum (Posted a comment)
  • -email is unavailable- added by joerg_wunsch (Posted a comment)
  • -email is unavailable- added by wutje (Posted a comment)
  • -email is unavailable- added by robertvknobloch (Submitted the item)
  •  

     

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-03-19 arcanum Open/ClosedOpen => Closed
    2008-03-08 dmix StatusIn Progress => Fixed
        Percent Complete40% => 100%
    2008-03-08 arcanum Assigned toarcanum => dmix
    2008-01-06 arcanum StatusNone => In Progress
    2008-01-06 arcanum Percent Complete0% => 40%
    2007-10-30 arcanum Assigned toNone => arcanum

    Back to the top


    Powered by Savane 3.5