tags:

views:

24

answers:

3

Hello all, Here is my question,

I work on an application embeded in a board we manufactured ourselves for a space project. The board uses a LEON2 Processor which is a derivate of SPARC v8 and we also use RTEMS as OS.

In this application we have to save default value for various tables for the FS in the EEPROM, so the user can modify them how he wants without having to do it everytime.

To achieve this I simply created a new section (.eeprom_data) and I placed it at address 0x6007cc40 which is in the EEPROM. It was done by using a specs file and a custom linker script which located the section at the correct address and told the compiler to put certain variables in this same section.

It seems to be working fine in this regard. Here is an extract of objdump for the section and one particular var:

6 .eeprom_data  000033c0  6007cc40  6007cc40  00038a80  2**3
              CONTENTS, ALLOC, LOAD, DATA

6007fbda g     O .eeprom_data 00000002 Downlink_Priority_Vc1_default_value

The only problem is that it seems not to be fully working. My application runs correctly with no problem but doing a simple test like this only partially work:

    Eeprom_ChipEnable(TRUE);
    managed_faulty_sectors_default_crc = 0x789A;
    tmp = managed_faulty_sectors_default_crc; 
    Eeprom_ChipEnable(FALSE);

The write operation which should write 0x789A in EEPROM does absolutely nothing The read operation however works perfectly and returns correctly the data that is stored in the memory.

I don't really know how to solve this problem so I hope someone can give me a hand.

Thanks, Léo.

A: 

Are you sure the data cache (if any) is flushed before you disable the EEPROM? And, are the EEPROM variables properly declared volatile?

Richard Pennington
A: 

Do you compile with optimization flags ? I'd guess the compiler to optimize away the write unless managed_faulty_sectors_default_crc is declared volatile .

Also how is managed_faulty_sectors_default_crc mapped to the .eeprom_data section - does objdump give any clue as to wether they're mapped correctly ?

nos
A: 

Thanks for your answers.

For some reason, when the HW engineer designed our board they did not allow the addressing of single 16 bits address only 32 bits address..

Leo