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

Нет об этом Вы должны заботиться сами:
'C' - __disable_interrupt(); __enable_interrupt();
asm - CLI; SEI

А есть ли возможность перекомпиллить данные библиотечные функции с запретом прервыаний в них? И где можно взять их исходники?

Эти функции не библиотечные. Они описаны и реализованы в intrinsics.h

Компиллер от IAR при обращении к переменным которые втиснуты в EEPROM всавляет свои процедуры.
т.е. если написать a = 5; он вызовет поппрограмку на асме которая в момент записи запретит прерывания а поосле окончания разрешит их. проверить это можно получив ассемблерный листинг своей программы ! Тоько вот забыл как компиллеру указать что переменная 'а' находится в EEPROM.
Но это можно узнать почитав доку !

Во-первых, там все учтено. По крайней мере, в версиях 4.xx. То есть, никаких дополнительных ухищрений с запрещением прерываний делать не нужно.

Во-вторых, все процедуры работы с eeprom можно поменять, подключив к проекту собственный файл, изменив тот, который лежит вот тут: \avr\src\lib\eeprom.s90

И учтите одну вещь: если будете делать как сказал BVU, огребете глюков по полной программе (особенно если есть обращение к EEPROM из обработчиков прерываний).

Так если программа только читает еепром зачем запрещать прерывания?

Вопрос возник всвязи с тем, что переменная в EEPROM таки портится!!! Есть подозрение, что если в процессе выполнения функции чтения происходит прерывание, то возможно и переполнение стека, и порча переменных в стеке CSTACK. Вот отсюда и вопрос про запрет прерывания.

Дык каков размер CSTACK, сколько байт ?

Размер CSTACK = 0х170 байт. Взял я этот размер из map файла:
Вот что там прописано


SEGMENT SPACE START ADDRESS END ADDRESS SIZE TYPE ALIGN
======= ===== ============= =========== ==== ==== =====
INTVEC CODE 00000000 - 0000004F 50 com 1
?FILL1 CODE 00000050 - 00000057 8 rel 0
NEAR_F CODE 00000058 - 00001A29 19D2 rel 0
SWITCH CODE 00001A2A - 00001A9B 72 rel 1
CODE CODE 00001A9C - 00006263 47C8 rel 1
INITTAB CODE 00006264 - 0000626F C rel 0
NEAR_ID CODE 00006270 - 000062ED 7E rel 0
ABSOLUTE DATA 0000001C rel 0
DATA 0000001D
DATA 0000001E
DATA 0000001F
DATA 00000020 - 00000027 8
DATA 00000029 - 0000002C 4
DATA 00000030 - 0000003B C
DATA 00000040 - 00000042 3
DATA 00000045 - 00000045 1
DATA 00000048 - 0000004B 4
DATA 0000004E - 0000004F 2
DATA 00000053 - 00000056 4
DATA 00000059 - 00000059 1
DATA 0000005B - 0000005C 2
CSTACK DATA 00000060 - 000001CF 170 dse 0
RSTACK DATA 000001D0 - 0000020F 40 dse 0
NEAR_I DATA 00000210 - 0000028D 7E rel 0
NEAR_Z DATA 0000028E - 000004B8 22B rel 0
EEPROM_I XDATA 00000001 - 0000012D 12D rel 0

Если вложенных прерываний не городили ! То такого размера должно хватить !
Кстати ! Если при чтении или записи в EEPROM не запрещать прерывания, а впрерываниях
есть ещё место где есть обращение к EEPROM или FLASH то данные в EEPROM могут слететь, даже
если идёт только чтение !

Ко FLASH есно по записи !

В том то и дело, что проект очень сложный и большой. Прерываний наверчено немеряно - все три таймера работают асинхронно с прерываниями, UART, TWI, INT0, INT1, INT2, и все это исключительно асинхронно.

Да, у меня в программе есть место, где в функции обработки прерывания идет чтение из EEPROM. Так это и может явиться причиной сбоя данных в EEPROM? Следует учесть, что, насколько я смог оценить последствия такого сбоя, сбивается всегда одна и та же ячейка.

Тогда нужно быть уверенным наверняка что в момент чтения или записи в EEPROM прерывания запрещены. 1 самому разрешать и запрешать, или дать на откуп компиллеру т.е. сказать ему что эти переменные находяться в EEPROM. (вот как это делается в IAR я не помню)

Сколько времени работаю с 'IAR Embedded Workbench 4.10B' и никаких проблем не возникало... Незнаю, как Вы работаете с EEPROM, а я предпочитаю не мудрить и использовать чтение/запись, как к обычным переменным объявленные в EEPROM. Просто посмотрите свой ассемблерный код после компиляции и все станет ясно, что на 'автомате' запрещение и разрешение прерываний там не генерируется. А в прерываниях на которые Вы сетуете необходимо учитывать автоматическое запрещение при входе в прерывание.

"Сколько времени работаю с 'IAR Embedded Workbench 4.10B' и никаких проблем не возникало... Незнаю, как Вы работаете с EEPROM, а я предпочитаю не мудрить и использовать чтение/запись, как к обычным переменным объявленные в EEPROM. Просто посмотрите свой ассемблерный код после компиляции и все станет ясно, что на 'автомате' запрещение и разрешение прерываний там не генерируется. А в прерываниях на которые Вы сетуете необходимо учитывать автоматическое запрещение при входе в прерывание."

Да ну ! Насколько я помню аж в 2.28 ну может в 3.10 при таком способе общения с EEPROM компиллер вставляет вызов подпрограмки (встроенной) в которой он и запрещает прерывания !

А если представить ситуацию, при которой происходит следующее:
Программа читает данные из EEPROM, в случайный момент времени, когда процесс получения данных еще не закончен, возникает прерывание, в теле которого происходит также доступ к EEPROM, однако уже к другим переменным. Что в итоге???? Возможна порча данных или нет?

Дык я про это и толкую !

Согласен, ошибался... нашел 'злачное место' в коде:
\ ?Subroutine23:
\ 00000000 94F8 CLI
\ 00000002 2D07 MOV R16, R7
\ 00000004 .... LDI R20, LOW(e_pressure)
\ 00000006 .... LDI R21, (e_pressure) >> 8
\ 00000008 .... RCALL __eeput8_16
\ 0000000A 9478 SEI
\ 0000000C 9508 RET
но как я понимаю эта процедура лишь для записи в eeprom...

Порча данных в самом EEPROM не возможна! А вот полученные данные могут быть не праивльными если между записью адреса в EEAR, установкой бита в EECR и чтением EEDR возникло прерывание, в которм есть чтение EEPROM, вы просто получите байт данных с другого адреса
Но сами данные в EEPROM портится не должны.

Я уже подробно говорил об этом.
В аттаче см. исправления для функций работы с EEPROM.

Замечательная дискуссия!
Спасибо всем. Я уже разобрался сам!
Действительно, удалось выяснить, что возникало наложение одной процедуры чтения на другую. Результат был неприятным.
Событие настолько редкое, что порой приходилось ждать по 3 суток его возникновения.
На решение таких задачек даже времени не жалко!!!

Я бы на Вашем месте, учитывая что обращения к EEPROM идет как из обработчика прерывания так и из основного цикла программы поступил бы следующим образом:

1. Взял бы даташит на контроллер с которым собираюсь работать.
2. Написал бы функции чтения/записи EEPROM руководствуясь даташитом с запретом прерываний. (ДЛЯ ИСПОЛЬЗОВАНИЯ ИЗ ОСНОВНОГО ЦИКЛА ПРОГРАММЫ)
3. Написал бы аналогичные функции чтения/записи EEPROM без запрета прерываний (ДЛЯ ИСПОЛЬЗОВАНИЯ ВНУТРИ ОБРАБОТЧИКОВ ПРЕРЫВАНИЙ)
4. Использовал бы только свои функции.

и не имел бы никаких проблем с затиранием.

PS: Доверия к тому, что IAR'е учтена возможность работы с EEPROM внутри обработчика прерывания у меня нет. А если этот момент не учтен, то обращение к EEPROM из обработчика прерывания приведет к разрешению прерываний и как следствие к повторному возбуждению одного и того же обработчика.

IAR C не только не запрещает прерывания при обращении к EEPROM, мало того - он даже не дожидается окончания записи (проверка окончания предыдущий записи осуществляется перед следующим обращением). Такой алгоритм обеспечивает наибольшую эффективность.

Поэтому, чтобы EEPROM не портилась, выходов 2.
1) Обрамлять каждое обращение к EEPROM запретом/разрешением прерываний, причем перед разрешением вручную дожидаться окончания записи
2) В прерывании сохранять/восстанавливать контекст EEPRM/ Вот пример из рабочего проекта:

#pragma vector=INT0_vect
__interrupt void USBNHandler(void)
{
char EAddr;
char EData;
//сохраняю контекст EEPROM
while(EECR&0x03); //жду окончания предыдущей записи (сброса EEWE, EERE)
EAddr=EEARL;
EData=EEDR;

//...обрабатываю прерывание, читаю-пишу EEPROM

//восстанавливаю контекст EEPROM
while(EECR&0x03); //жду сброса EEWE, EERE
EEARL=EAddr;
EEDR=EData;
}

Ну и третий, самый разумный подход - отказаться от обращения к EEPROM в прерываниях

sz36
4-й выход - перейти на CodeVision