[aal 0]

Была прога написанная имено под AT90S8535. Сейчас потребовалось сделать несколько таких девайсов. Естественно закуплена была mega8535. При установке бита совместимости всё работает, но запись в EEPROM не происходит (проверенно). С AT90S8535 всё впорядке - работает.

Вот код записи чтения байта в/из EEPROM. В чём прикол понять немогу.

IAR.

void EEPUT(unsigned int ADR,unsigned char data)
{ unsigned int err=0;
 while (--err && (EECR & (1<<EEWE)));
 if (err && good1)
 {
   CLI;
   EEAR = (ADR & 0x01ff);
   EEDR = data;
   EECR = (1<<EEMWE);
   EECR = (1<<EEWE);
   EEAR = 0;
   SEI;
 }
}

unsigned char EEGET(unsigned int ADR)
{ unsigned int err=0;
 unsigned char t;
 while (--err && (EECR & (1<<EEWE)));
 if (err)
 { EEAR = (ADR & 0x01ff);
   EECR = (1<<EERE);
 }
 EEAR = 0;
 t = EEDR;
 return (t);
}

 

Частота 5 МГц. Т.е. задержка ожидания готовности до 0,15с - в 20 раз перекрывает время записи.

Да и по ерате вроде проблем небыло. Не может же 5 мег дохлых быть изодной партии и подряд.

Хотя сейчас именно мысль появилась - если запись привязана к внутреннему рц генератору, то может он накрылся?

[BVU 0]

Посмотрите это, может поможет:

 

http://forum.electronix.ru/index.php?showtopic=6785

http://forum.electronix.ru/index.php?showtopic=6843

[aal 0]

Это я всё уже читал. Здесь какая-то заковырка с миграцией....

[Karl 0]

Было что-то подобное. Связано с медленным чтением/записью в еепром. При записи советую проверять битик eewe.

wr_eeprom:

push ZL

push ZH

push c

push temp

in temp,sreg

push temp

cli

out eearl,zl

out eearh,zh

out eedr,c ;данные

wait_end_wr:

sbic eecr,eewe ;ожидание освобождения eeprom

jmp wait_end_wr

sbi eecr,eemwe

sbi eecr,eewe

wait_end_wr1:

sbic eecr,eewe ;ожидание окончания записи

jmp wait_end_wr1

 

pop temp

out sreg,temp

pop temp

pop c

pop ZH

pop ZL

ret

 

Еще при переходе на мегу в одном из проектов помог "разгон" RC - генератора.

[BVU 0]

Это я всё уже читал. Здесь какая-то заковырка с миграцией....

<{POST_SNAPBACK}>

 

http://forum.electronix.ru/index.php?showtopic=6785

 

Данным примером Вым предлагают работать с EEPROM, как с обыкновенной статической памятью. А Вы пишите свои функции записи в EEPROM. Лучше за Вас это сделает компилятор (более правильно для данного вида контроллера).

Зачем такая головная боль - непонятно...!?

[KRS 0]

Может быть проблема с верменем записи (вотчдог срабатывает или другие таймауты)

Дело в том что если раньше у вас был 8535 на 8 МГЦ - он писал еепром в 8 раз быстрее чем сейчас пишет mega потому что у меги еепром пишется от внутреннего генератора на 1 мгц, у меня как раз были проблемы именно с этим

[aal 0]

Связано с медленным чтением/записью в еепром.

unsigned int err=0;
while (--err && (EECR & (1<<EEWE)));//время ожидания до 0,15с.

Дело в том что если раньше у вас был 8535 на 8 МГЦ - он писал еепром в 8 раз быстрее чем сейчас пишет mega потому что у меги еепром пишется от внутреннего генератора на 1 мгц,

У меня 5 МГц кварц и на 90 и меге. Ждём до 0,15 с готовности eeprom.

[KRS 0]

У меня 5 МГц кварц и на 90 и меге. Ждём до 0,15 с готовности eeprom.

Не важно какой кварц на меге, еепром у меги работает от всторенного генератора 1 мгц 8448 тактов т.е примерно 8.4 ms

 

 

И ззачем вы перед чтением данных из EEDR устанавливаете EEAR в 0

скорее всего бага здесь!

[aal 0]

И ззачем вы перед чтением данных из EEDR устанавливаете EEAR в 0

По рекомендациям и в EEPUT и в EEGET, после работы, адрес в 0 сбрасываю, чтоб при "случайной записи" слетела именно 0 ячейка. Чтение работало.

 

В принципе уже разобрался. У меня есть цепочка на оптроне формирователь импульсов от сети 50 Гц. Для контроля наличия. Так на платах перевернули диод, импульсов нет, и прога считает, что сеть пропала, запрещает запись. Переменная GOOD1.

 

Выматерился, но это ещё неконец. При старте всеравно где-то виснет....В процессе записи.

[KRS 0]

А может логичнее адрес выставлять в 0 после чтения?

[aal 0]

Без разницы - читает нормально. Ведь результат операции в регистре.

[Karl 0]

Может быть проблема с верменем записи (вотчдог срабатывает или другие таймауты)

Дело в том что если раньше у вас был 8535 на 8 МГЦ - он писал еепром в 8 раз быстрее чем сейчас пишет mega потому что у меги еепром пишется от внутреннего генератора на 1 мгц, у меня как раз были проблемы именно с этим

<{POST_SNAPBACK}>

 

как раз то же самое было и у нас.

[vzyk 0]

   CLI;

   EEAR = (ADR & 0x01ff);

   EEDR = data;

   EECR = (1<<EEMWE);

   EECR = (1<<EEWE);

   EEAR = 0;

   SEI;

 

Hello,

Very strange line is EEAR=0.. Remove it! You are resetting (or at least accessing) address register at the moment, when you are trying to write to EEPROM;

 

If it will not help, - try to remove your waiting circle, and after writting data, add some delay after write strobe (~10mS, according to data sheet). And will work.

 

P.S. Sorry for English...

[Jocker 0]

Даю свою процедуру, если тебе еще нужно.

У меня работает на 100 проц. в реальном девайсе

 

;.def Tmp0 = R16

;.def Tmp1 = R17

 

; addr in ZL, ZH

; byte is in Tmp0

WriteEEPROMByte:

push Tmp1

in Tmp1, SREG

push Tmp1

WAIT_EEWR

cli

out EEARL, ZL

out EEARH, ZH

 

out EEDR, Tmp0

sbi EECR, EEMWE

sbi EECR, EEWE

 

pop Tmp1

out SREG, Tmp1

pop Tmp1

ret

[aal 0]

Спасибо всем!

 

Я уже нашёл причину. В инициализации есть функция стирания еепром, если все данные "битые". Вот она и привышала по времени период ватчдога. Мои грабли. В АТ90 успевало стерется, а в меге нет...

 

Т.е. было 2 ошибки:

1. Неработал узел детекции сетевого напряжения. И запрещал запись.

2. Привышение времени ватчдога, при стирании еепром.

 

Переборщил с защитой и в 1 и 2 случае. А симптомы указывали на отсутствие записи в еепром.