Перейти к содержанию
    

И снова самопрограммирование Mega88

Итак.

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

Проблема в следующем - памяти впритык,осталось около 256байт, т.е. хотелось бы использовать самые верхние адреса флэш, скажем с адреса 0xFE0. Но эта область уже вроде как определена под бутлоадер.

Вопрос: можно ли из своего кода сохранить параметры в этой области? Или это не возможно в принципе?

Пробовал писать в эту область - результат - 0. Впрочем как и в любую другую, даже в области памяти программ. Код для этого должен лежать в области бутлоадера? Если так - как затолкать туда функции для работы с флэш средствами CodeVision, чтобы основной код лежал в программной области, а нужное - в буте?

 

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

base_adress = (*(( unsigned char flash*) 0x0600));

результат - какая-то фигня. Хотя по смыслу вроде правльно. Адрес выбран произвольно и там другие значения.

 

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

Фузы - никаких ограничений нет.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

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

 

Проблема в следующем - памяти впритык,осталось около 256байт, т.е. хотелось бы использовать самые верхние адреса флэш, скажем с адреса 0xFE0. Но эта область уже вроде как определена под бутлоадер.

Вопрос: можно ли из своего кода сохранить параметры в этой области? Или это не возможно в принципе?

Пробовал писать в эту область - результат - 0. Впрочем как и в любую другую, даже в области памяти программ. Код для этого должен лежать в области бутлоадера? Если так - как затолкать туда функции для работы с флэш средствами CodeVision, чтобы основной код лежал в программной области, а нужное - в буте?

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

#pragma location="BOOT"
void PageLoader( unsigned int flash_address, unsigned char *buffer)
{ int i;
  _WAIT_FOR_SPM();
  _SPM_ERASE( flash_address);
  _WAIT_FOR_SPM();
  _ENABLE_RWW_SECTION();
  for( i=0; i < 128; i++)  _SPM_FILLTEMP( i << 1, ((int*)buffer)[i]);
  _WAIT_FOR_SPM();
  _SPM_PAGEWRITE( flash_address);
  _WAIT_FOR_SPM();
  _ENABLE_RWW_SECTION();
}

А после этого вызываю эту функцию, из нижнего кода, когда мне нужно что-то записать во флэш.

При этом адрес флеши у меня int-овый (2-х байтный), т.к. флеш раздается словами, а не байтами.

 

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

base_adress = (*(( unsigned char flash*) 0x0600));

результат - какая-то фигня. Хотя по смыслу вроде правльно. Адрес выбран произвольно и там другие значения.

Чтение флэш идет тоже по словному адресу, а не байтному. Хотя компиляторы уже потом могут вырезать нужный байт. Но это где как.

Число в адрес преобразуется напрямую:

unsigned char flash *base_adress = (unsigned char flash*)0x0600;

Только, думаю, что такого рода адрес вам вряд ли понадобится.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

Про

base_adress = (*(( unsigned char flash*) 0x0600));

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

Для корректности пусть будет:

Param1 = (*(( unsigned char flash*) 0x0600));

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Имеется проектик на CodeVisionAVR, Mega88.

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

Да, в правильно спроектированном приборе при включенном супервизоре EEPROM слетать не должна ...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

С бутлоадером более или менее понятно - примеров море.

А вот как параметры хранить - не понятно. Как разделить код по областям в кодевижн - тоже.

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Например во время обращения к епром выдергивают батарею - и все. Флэш как-то надежнее...

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Изменено пользователем SmarTrunk

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Да все это понятно. Но, девайс УЖЕ ЕСТЬ. Его очень много наделано. И в каждый нужно зашить его номер. Вариант с компиляцией под каждый экземпляр, что сейчас и делается, это очень долго.

Сейчас задача - сделать запись этих параметров во флэш.

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

Так что именно нужно записать блок с параметрами конкретного устройства по каким-либо свободным адресам. Вопрос - как?

Опять-же, когда код лоадера сидит в своей области памяти - все ясно, более или менее, но тут нужно все объединить в проекте.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вариант с компиляцией под каждый экземпляр, что сейчас и делается, это очень долго.

 

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Идеальный вариант - разобраться с самопрограммированием, в данном виде.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...