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: NoneSeverity: 3 - Normal
Priority: 5 - NormalItem Group: libc code
Status: FixedPercent Complete: 100%
Assigned to: Dmitry Xmelkov <dmix>Open/Closed: Closed
Release: NoneFixed 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 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 File(s):
   
   
Comment:
   

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

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

     

     

    Follow 7 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 19 Mar 2008 10:28:28 PM UTCarcanumOpen/ClosedOpen=>Closed
    Sat 08 Mar 2008 10:49:11 PM UTCdmixStatusIn Progress=>Fixed
      Percent Complete40%=>100%
    Sat 08 Mar 2008 02:21:24 PM UTCarcanumAssigned toarcanum=>dmix
    Sun 06 Jan 2008 04:00:17 AM UTCarcanumStatusNone=>In Progress
    Sun 06 Jan 2008 03:59:44 AM UTCarcanumPercent Complete0%=>40%
    Tue 30 Oct 2007 12:43:45 PM UTCarcanumAssigned toNone=>arcanum

    Back to the top


    Powered by Savane 3.1-cleanup1