Снова разбираюсь с еепром хмеги(128A).
Возникло несколько вопросов:

1. Для чего придумали NVM контроллер (чем не устроил подход как в обычных мегах)?
только лишь для паралельной записи страницы? или еще какие цели преследовались?

2. Если включён режим отображения еепром в области данных (0x1000:0x17FF) то, поскольку страница = 32 байта,
запись по адресам 0х1000 и 0х1020 приведёт к абсолютно одинаковому результату : записи по нулевому адресу страничного буфера еепром?

2. Если за 1 раз будете писать не более 32 байт, то запись в эти адреса приведет к разным результатам. Кроме того, учтите, что в полной мере работа EEPROM в режиме отображения на память поддерживается только при чтении. При записи это всего лишь заполнение буфера страницы, после которого надо давать в NVM команду записи.

1. Одна из причин введения специализированного NVM - как раз введение режима отображения на память. Но там их (причин) наверняка больше. Возможно, вторая - некоторая унификация процедур работы с EEPROM и с памятью программ.

Похоже я не совсем понимаю что из себя представляет страничный буфер еепром.
Это просто один массив из 32-х байт с адресами оных 0x00-0x1F или это N массивов по 32 байта для каждой страницы или нечто другое???

Один буфер на всю eeprom. Очень похоже на страничный буфер flash-памяти в мегаАВР.
Подробности можно посмотреть в AVR1315 (doc8066.pdf).


Ещё фича - чтение eeprom с помощью DMA.


PS. Не забуьте про ерату и ревизию - eeprom там тоже упоминалась.

А почему тогда запись по адресам 0х1000 и 0х1020, как утвеждает V_G, дадут разный результат?


До ерраты пока далеко, надо пока вообще с принципом разобраться.

Логика в этом предположении есть, но зачем использовать такой режим? Он как бы не рекомендован и соответственно неизвестно, как будет работать.


Может V_G проверял?
Мне сейчас проверить не начем, а симулятор чето не хочет eeprom писать...
Надо в жеезе испытать - инересно что и куда запишется.

Не рекомендован??? где конкретно в DS это не рекомендуют? ну или хотябы где рекомендуют писать только по адресам 0x1000-0x101F.


Проверять буду позже. Пока хочу досконально понять хотябы то что в DS написано.

И попутно вопросы:
В "AVR1315" сказано что повторная запись по одному и томуже адресу страничного буфера еепром выглядит как логическое И содержимого и записываемого.
Интересно зачем так сделано если буфер это вроде как обычное озу?
С еепром понятно, там ноль жжётся, а с буфером то зачем?

Если выполнить команду записи страницы еепром с NVM_ADDR2..0 = 0х000000 или 0х00001F будет ли в обоих случаях записана нулевая страница?

Про 0x1000-0x101F ничего не скажу...
Вот из AVR1315

D примере, идущем с апнотой, несколько раз повторяется, что данные должны быть в пределах одной страницы.


Наверно подобие flash изображают...буфер оно конечно озу, но flash-то не озу.



Почему должна быть нулевая страница? Сколько у вас станиц всего? 32 или 64?

Всего 64 страницы по 32 байта.
Что нужно записать в NVM_ADDR2..0 для записи буфера в 0-ю, 1-ю и т.д. страницу?



И причём здесь flash? Речь о еепром.
Понятно что они что то изображают и даже понятно что изображают, но зачем они это изображают? видать какой то тайный смысл в этом есть.

Любой адрес в пределах страницы(если я правильно понял):




Опечатался...конечно eeprom.


Не вижу особого смысла в этом "изображении".
Так они сделали.

Cовсем я запутался
Можно конкретней, что должно быть в NVM_ADDR2..0 для записи НУЛЕВОЙ страницы еепром (в случае отображения еепром в область данных с адреса 0x1000)?
любой из 0x000000-0x00001F или любой из 0x001000-0x00101F ?

Судя по их примерам - 0x000000-0x00001F

Я,к сожалению, в СИ не силён. Но вот это из EEPROM_DRIVER.H

не означает ли что всётаки любой из 0x001000-0x00101F ?

А на асме случайно нет примеров???

к сожалению...но сильным быть-то и не надо, самую малость понимать уже хватило бы.



Тут какой-то другой случай - параметров у макроса 2 (номер страницы и намер байта на старнице).

А для доступа как к ОЗУ используется EEPROM(addr):

EEPROM(TEST_ADDR_1) = TEST_BYTE_1; - это обращение(запись) к EEPROM как к ОЗУ по адресу (0x1000+TEST_ADDR_1)
А запись вот:

- используется адрес не (0x1000+TEST_ADDR_1), а TEST_ADDR_1 - равный в примере 1


Есть...почти: запускается проект на отладку и открывается окно дисасемблера. Ну, тоже вариант.

Конечно, у меня и запись и чтение идут в этом режиме. Особенность в том, что старший байт адреса (и старшие 3 бита младшего байта) сохраняются как адрес страницы, а младшие 5 бит определяют адрес в страничном буфере.
После команды записи содержимое страничного буфера программируется в разные места EEPROM в зависимости от содержимого старших разрядов адреса.

Как это делается на Си, не разбирался, т.к. под АВР пишу на ассемблере

Спасибо _Артём_ и V_G, тереь становится яснее.

Попытаюсь слегка резюмировать то что я понял. Поправте ещё раз ежели не прав.

Итак, страничный буфер еепром это один 32-х байтных массив при записи в который почемуто происходит лог. И .
В режиме отображения в область данных писать в этот буфер можно по любым адресам 0x1000-0x17FF (старшие биты адреса игнорируются).
Количество этих записей не ограничено, ни что не мешает выполнить сто раз запись по одному и томуже адресу.
Для записи буфера в страницу еепром необходимо выполнить команду NVM с ADDR равным любому адресу записываемой страницы (младшие биты адреса игнорируются).

PS. похоже что при записи буфера в страницу еепром игнорируются не только 5 младших адресов а и адреса старше A10.

Вы бы еще ревизию чипа читали перед использованием eeprom. В xmega128a1 до ревизии чипа H, был неприятный баг. У меня проявлялся следующим образом (тоже использовал map ram), при записи в eeprom контроллер прыгал на произвольный адрес flash. Нормально запустить получилось, только когда применил workaround из errata. Запись в eeprom - впадение ядра в idle - просыпание по прерыванию об окончании записи в eeprom.
Первые партии xmega разных серий страдали этой бажиной, потом они ее пофиксили. Здесь как повезет. Мне два таких попалось, потом нормальные стали приходить.

Немного о причинах введения NVM контроллера. На мой взгляд одна из причин это организация постраничного доступа. В AVR постраничный доступ был доступен только через программатор. Мне в софте приходится сливать в eeprom большие массивы данных, в xmega это не в пример быстрее происходит из-за постраничной организации.

Капец!
С освоением хмег не спешил, ждал когда побольше багов выловят.
У меня все rev.H. Проверяю по старту и ругаюсь на более раннюю.

Да. конечно полезная штука.
я тоже хотел ею воспользоваться чтоб дополнительно сэкономить на озу.
чип мега 128а3
задумка была при постоянном включенном маппинге работать с калибровочными таблицами.

Но к сожалению, так и не удалось довести до релиза.
Хаотически появлялись глюки с записью в еепром.
3 месяца гонял свой софт из шкуры вылез, но так и не добился устойчивой работы NVM.
Пришлось по старинке грузить таблицы в озу.
Причины сбоев так и не смог опредлить.

Да и с включенным маппингом студия4+avr Jtag mkII+ активное окно: содержимое EEPROM - тоже дурит не по детски.

Я применяю atxmega32a4, никаких подобных проблем не встречал. При отладке в Студии4 иногда затирается ячейка 0 EEPROM, но эта штука где-то описана.
EEPROM у меня используется на запись относительно часто, каждый раз при выключении питания пишется страница статуса (32 байта), 100 мкФ по питанию вполне хватает для удержания питания на время записи.

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

А как узнать время записи страницы еепром при тактировании проца от внутр. 32 MHz?
В DS на хмега128A (п. 33.4 Flash and EEPROM Memory Characteristics Table 33-4. Programming time) указано 6 ms но только для внутр. 2 MHz.

Вернулся старый глюк meg, про который все уже забыли?

Я бы сказал глюк at90s, т.к. в мегах ИМХО его уже не было.
Я до сих пор во всех AVR проектах нулевой байт eeprom'a резервирую:-)

Да нет это проявляется только при отладке
и при включенном мапинге и открытом окне содержимого еепрома
(покрайне мере у меня 100 % затирание ячейки- одна или несколько уже не помню)
я так понимаю студия читает содержимое еепрома не используя маппинг
если за этим следить (руками ставить\убирать флаг) то проблем нет
хотя конечно напрягает.



если не сложно не могли бы вы показать код того момента, когда происходит запись еепрома (особенно когда произходит переключения с маппинга на нормальный режим)
если конечно не напрягает :-)
если асм - это даже лучше

Я не использую нормальный режим и на него соответственно не переключаюсь

Спасибо за код.
то есть вы работаете с постоянно включенном маппинге
не знаю почему, но я всегда считал, что запись в еепром должна производиться при выключенном маппинге
может отсюда все мои проблемы?

При переходе в спящие режимы запись в еепром останавливается или нет?

Аналогичное поведение в IAR.



В IDLE продолжает писать. В power save\down с памяти снимается тактовая, так что не должен писать, остальные не пробовал.

ОК.

Еще вопрос:
При выключении питания проц уходит в power save и питается от резервного CR2032, просыпаясь раз в секунду инкрементирует счётчик времени и проверяет не появилось ли основное питание.
Всё ОК, пол года полёт нормальный.
Но есть одна проблемка.
Если отключить и резервное питание то по сбросу счётчику времени кирдык.
Сейчас при сбросе просто инициализирую счётчик временем прожига проца.
Но хочется что бы время не сбрасывалось а хотябы просто останавливалось.
Планирую раз в минуту писать счётчик в еепром.
Время стирания/записи страницы еепром 12ms и потребление 30mA.
Как прикинуть на сколько быстрее сдохнет батарейка если дополнительно каждую минуту при просыпании бросать текущее время в еепром?

Ничего себе - так долго пишет и много жрёт.

А ничего, что в году 525600 минут, и кирдык настанет EEPROM'у?
Обходитесь ионистором.

Это согласго DS, сам тестов не проводил.

Да ничего, размажу запись по епрому.

А ионистор то зачем?

Ионистор вместо резервной батарейки. Срок службы огромный, режим - как раз под резерв питания проца. Посчитайте, сколько продержит ионистор на 1Ф питание вашего проца в вашем полуспящем режиме. Глядишь, часы придется сохранять не раз в минуту, а раз в месяц!

Что то я не пойму, Вы хотите сказать что от ионистора проц в полуспящем режиме проработает дольше чем от батарейки???

Вроде посчитал на сколько повышается среднее потребление проца при записи еепром каждую минуту.
И получилось больше в 145 раз!!!
Видать от этой идеи придётся отказаться.

Я не знаю режима работы вашего устройства при питании от резервного источника. Если это источник действительно только резервный, а не основной (т.е. используется редко, на время отключения электроэнергии), то есть смысл применения ионистора, он проработает много дольше батарейки. У меня на контроллерах светофоров стоит ионистор на часы реального времени. За 14 лет работы жалоб на ионисторы не было. Часы (pcf8593) держатся до 2 месяцев после отключения основного питания. А теперь посчитайте, сколько раз за эти 14 лет пришлось бы менять батарейки, с учетом того, что девайсы стоят на улице.

в каких то старших хмегах есть (RTC с батарейкой)
но к сожалению только в страшей.. А так с удовольствием поюзал бы эту штуку
а пока только ds1340+ ионистр

2 месяца мне не достаточно. Изделие не уличное и батарейку поменять проще.
А вот интересно по чём нынче стоят ионисторы на 1Ф при партии 500-1000 шт? Батарейки беру по $0.20.


Аналогично, а в каких таких старших хмегах такое есть ???

ATXMEGA256A3B, ATXMEGA256A3BU

Жаль, меня только A1 интересуют.

Вот еще вопрос возник:
Можно ли переключать источник тактирования проца во время записи NVM контроллером страницы еепром ?

Почему нельзя? Нет ведь каких-то указаний, запрещающих переключение источников.