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

 
 

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

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

Submitter:  Robert von Knobloch <robertvknobloch>
Submitted:  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:  dmix
Percent Complete:  100% Open/Closed:  Closed
Release:  None Fixed Release:  None

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>
Group administrator
Sat 08 Mar 2008 02:21:24 PM UTC, comment #5: 

Changing owner to Dmitry.

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

Deferred until 1.6.1.

Eric Weddington <arcanum>
Group 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>
Group 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>
Group 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.)

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.13-02a9.
    Corresponding source code