Неожиданное поведение операций записи при создании пользовательского раздела в EEPROM с использованием GCC - PullRequest
Новая
       37

Неожиданное поведение операций записи при создании пользовательского раздела в EEPROM с использованием GCC

2 голосов
/ 04 декабря 2009

Вот мой вопрос,

Я работаю над приложением, встроенным в доску, которую мы изготовили для космического проекта. На плате используется процессор LEON2, производный от SPARC v8, и мы также используем RTEMS в качестве ОС.

В этом приложении мы должны сохранить значение по умолчанию для различных таблиц для FS в EEPROM, чтобы пользователь мог изменять их так, как он хочет, без необходимости делать это каждый раз.

Для этого я просто создал новый раздел (.eeprom_data) и разместил его по адресу 0x6007cc40, который находится в EEPROM. Это было сделано с помощью файла спецификации и специального сценария компоновщика, который разместил раздел по правильному адресу и велел компилятору поместить определенные переменные в этот же раздел.

Кажется, в этом отношении все работает нормально. Вот выдержка из objdump для раздела и одной конкретной переменной: 

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

6007fbda g     O .eeprom_data 00000002 Downlink_Priority_Vc1_default_value

Единственная проблема заключается в том, что она не работает полностью. Мое приложение работает без проблем, но простой тест, как этот, работает только частично: 

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

Операция записи, которая должна записать 0x789A в EEPROM, абсолютно ничего не делает Операция чтения, однако, работает отлично и корректно возвращает данные, хранящиеся в памяти.

Я действительно не знаю, как решить эту проблему, поэтому я надеюсь, что кто-нибудь может мне помочь.

Спасибо, Лео.

Ответы [ 3 ]

1 голос
/ 08 декабря 2009

Спасибо за ваши ответы.

По какой-то причине, когда инженер HW разработал нашу плату, они не разрешали адресацию одного 16-битного адреса только 32-битным адресом.

0 голосов
/ 04 декабря 2009

Вы компилируете с флагами оптимизации? Я полагаю, что компилятор оптимизирует запись, если не указано, что managed_faulty_sectors_default_crc является энергозависимым.

Кроме того, каким образом managed_faulty_sectors_default_crc отображается в разделе .eeprom_data - дает ли objdump какой-либо ключ к правильному отображению?

0 голосов
/ 04 декабря 2009

Вы уверены, что кэш данных (если есть) очищается перед отключением EEPROM? И правильно ли переменные EEPROM объявлены как volatile?

...