Итак.
Имеется проектик на CodeVisionAVR, Mega88. Достался в наследство, портировать в другую среду категорически ломает, поэтому необходимо выжать максимум из того, что есть. Имеются некоторые параметры конфигурации, которые хотелось-бы хранить во флэш. Епром не подходит, поскольку имеется высокая вероятность его "слета" - питание батарейное и пользователи совсем не парятся с аккуратностью.
Проблема в следующем - памяти впритык,осталось около 256байт, т.е. хотелось бы использовать самые верхние адреса флэш, скажем с адреса 0xFE0. Но эта область уже вроде как определена под бутлоадер.
Вопрос: можно ли из своего кода сохранить параметры в этой области? Или это не возможно в принципе?
Пробовал писать в эту область - результат - 0. Впрочем как и в любую другую, даже в области памяти программ. Код для этого должен лежать в области бутлоадера? Если так - как затолкать туда функции для работы с флэш средствами CodeVision, чтобы основной код лежал в программной области, а нужное - в буте?

Еще вопрос. Пытаюсь прочитать те самые параметры конфигурации, да в прочем любые данные из флэш вот так:
результат - какая-то фигня. Хотя по смыслу вроде правльно. Адрес выбран произвольно и там другие значения.

Разместить изначально константы во флэш по нужным адресам CodeVision не дает.
Фузы - никаких ограничений нет.

Кто что подскажет?

Тогда почему бы вам не заменить Мегу88 на Мегу168 или Мегу328? У них кортуса и цоколевки одинаковые, а памяти больше. Прошивку, конечно, придется перекомпилировать, но у вас же код на С, а не на ассемблере, значит, проблем быть не должно.


Слёт флэш ничуть не лучше слёта епром . Вряд ли в таких условиях запись во флеш будет надежнее.


Возможно. Вот только я на IARе программирую и не на Меге88, а потому про CodeVision сказать не могу, но сама в таких случаях поступаю так. Т.е. пишу функцию копирования ОЗУ в ПЗУ и размещаю ее в BOOT-области (для последнего требуется указать pragma location):

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


Чтение флэш идет тоже по словному адресу, а не байтному. Хотя компиляторы уже потом могут вырезать нужный байт. Но это где как.
Число в адрес преобразуется напрямую:
unsigned char flash *base_adress = (unsigned char flash*)0x0600;
Только, думаю, что такого рода адрес вам вряд ли понадобится.

Устройств уже "тыщщи" наделаны... Допиливаю софт и потихоньку внедряю. Потому Мега168 может и будет, но пока все не выжмется из этого и не распродастся - будет так...

Про

Не ясно выразился - это собственно сам параметр. Называется так. С адреса 600 нужно вязть его значение.
Для корректности пусть будет:

Mega88, CodeVision. Делал очень похожую штуку - в области загрузчика размещал свой программный код, ответственный за обновление ПО устройства, который умел закачивать это самое ПО по I2C и записывать его в память программ. Сам загрузчик никогда и ни при каких условиях не переписывался. Все ПО загрузчика было написано на АСМе. За основу был взят апп.ноут от Атмела ...
Да, в правильно спроектированном приборе при включенном супервизоре EEPROM слетать не должна ...

С бутлоадером более или менее понятно - примеров море.
А вот как параметры хранить - не понятно. Как разделить код по областям в кодевижн - тоже.
Не всегда возможно и нужно использовать всяческие супервизоры и т.п. Да и не панацея. Например во время обращения к епром выдергивают батарею - и все. Флэш как-то надежнее...

Если выдернуть батарею при записи во флешь будет гораздо хуже - слетит целый блок.

Все время храню параметры в eeprom - никогда слетов не было.

Параллельно батарее подключите конденсатор или ионистор достаточной емкости. МК получает сигнал о том, что батарею выдернули (например, от супервизора - не пытайтесь экономить на необходимом), и корректно завершает сеанс работы с Flash за счет энергии, накопленной в конденсаторе. В чем здесь проблема, я не понимаю, честно говоря ...

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

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

Да все это понятно. Но, девайс УЖЕ ЕСТЬ. Его очень много наделано. И в каждый нужно зашить его номер. Вариант с компиляцией под каждый экземпляр, что сейчас и делается, это очень долго.
Сейчас задача - сделать запись этих параметров во флэш.
Требования чтобы все сидело именно во флэш. Епром не использовать вообще. Ну вот так. Плюс проект уже в кодевижн. Переносить его мне крайне лениво, да и не целесообразно.
Так что именно нужно записать блок с параметрами конкретного устройства по каким-либо свободным адресам. Вопрос - как?
Опять-же, когда код лоадера сидит в своей области памяти - все ясно, более или менее, но тут нужно все объединить в проекте.

A зачем перекомпилировать? Написать программу в 3 стройчки которая заменяет несколько байт в HEX фаиле и соответственно checksum.

Так исторически сложилось. Проект не мой. Допиливаю, доделываю, привожу в человеческий вид, по мере необходимости. Естестввенно писать просто так что-то - лениво. Да и это из разряда костылей.
Идеальный вариант - разобраться с самопрограммированием, в данном виде.

Мы как-то делали деталь на 64 меге, в которой данные и параметры писались во флешь в процессе работы. Все было сделано очень аккуратно, все рекомендации были соблюдены, питатель гарантировал нужное напряжение на время записи (т.е. сигнал PowerGood, прерывания запрещались и т.д. и т.п.). И все отлично работало почти всегда. Но, крайне редко, обнаруживали порчу данных во флеше. Причину и возможные варианты искали долго и безуспешно. Самая вероятная причина - какие-то редкие недокументированные сбои в харде записи во флешь в проце. Плюнули и перешли на EEP, все сбои прекратились.