Как сохранить пару байт во FLASH?, FLASH & MSP430 Опции

[Lucky:)]

Мне нужно держать с десяток текущих переменных в энергонезависимой памяти. Хочу для этой цели использовать FLASH.

Как я понял записать байт во FLASH в одно и тоже место дважды нельзя (т.е. перезаписать байт). Предварительно это место надо стереть. А стирание осушествляется только сегментом (например в 123ем - 128байт).
т.е. перед тем как чего записать, надо скопировать сегмент куда либо, стереть старые данные и перезаписать новыми.

Есть ли более удобный метод сохранить пару байт во внутренней памяти MSP430?

[HARMHARM]

Это и есть удобный метод
Неспроста у MSP430 два сегмента памяти. Заполняете один записями, стираете второй и заполняете его, обеспечивая непрерывность процесса. Запись неплохо бы дополнить CRC. Если интересно, могу дать свой код, использующий эти сегменты, правда в очень простом варианте и с одним багом

P.S. На ассемблере. Кстати, эти сегменты везде по 128 байт. А байты презаписывать можно, но только нулевыми битами.

Сообщение отредактировал HARMHARM - Jan 9 2007, 13:00

[exSSerge]

После непродолжительной борьбы с этими сегментами я пришёл к выводу что при наших тиражах проще поставить внешнюю EEPROM с I2C или SPI интерфейсом - будет дешевле и быстрее.

[rezident]

После непродолжительной борьбы с этими сегментами я пришёл к выводу что при наших тиражах проще поставить внешнюю EEPROM с I2C или SPI интерфейсом - будет дешевле и быстрее.

На самом деле использование/не использование внутренней FLASH MSP430 определяется несколькими факторами.
- объем сохраняемой информации
- частота сохранения записей и время единичной записи
Если первый определяет в основном лишь сколько сегментов нужно резервировать во Flash под записи, то у второго контекст гораздо больше. Потому как тут вступают в силу многие факторы, например,
ресурс Flash MSP430,
минимальное время необходимое для записи в течение которого программа тормозится или может выполняться только из ОЗУ,
минимальное время для резервирования питания и т.д.
Так что ваш вывод не совсем верен. Когда в очень простом, но серийном устройстве нужно сохранить с десяток байт, которые пользователь меняет скажем не чаще нескольких раз в день, то зачем мне доп. затраты в несколько $ на внешнюю EEPROM? Если я могу их спокойно добавить себе в прибыль, один раз, но досконально разобравшись с внутрипрограммным программирование Flash?

[Lucky:)]

Это и есть удобный метод

Tak вот он какой, "северный олень".

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

P.S. На ассемблере. Кстати, эти сегменты везде по 128 байт. А байты презаписывать можно, но только нулевыми битами.

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

[Dog Pawlowa]

... я пришёл к выводу что при наших тиражах проще поставить внешнюю EEPROM с I2C или SPI интерфейсом - будет дешевле и быстрее...

...На самом деле использование/не использование внутренней FLASH MSP430 определяется несколькими факторами...

Я в уже разработанное устройство, работающее с флэш, тоже поставил EEPROM по совокупности этих факторов.
И еще одного фактора - мне кажется, что наличие кода стирания и записи флэш снижает надежность устройства, особенно при работе в условиях помех.
Быо бы интересно услышать Ваше мнение.

[Lucky:)]

И еще одного фактора - мне кажется, что наличие кода стирания и записи флэш снижает надежность устройства, особенно при работе в условиях помех.
Быо бы интересно услышать Ваше мнение.

согласен

[rezident]

И еще одного фактора - мне кажется, что наличие кода стирания и записи флэш снижает надежность устройства, особенно при работе в условиях помех.
Быо бы интересно услышать Ваше мнение.

Без нормального супервизора питания использование внутрипрограммной перезаписи Flash вообще противопоказано!

[Dog Pawlowa]

И еще одного фактора - мне кажется, что наличие кода стирания и записи флэш снижает надежность устройства, особенно при работе в условиях помех.
Быо бы интересно услышать Ваше мнение.

Без нормального супервизора питания использование внутрипрограммной перезаписи Flash вообще противопоказано!

Ну, без нормального, желательно от TI, супервизора вообще использование MSP весьма чревато :-)

[HARMHARM]

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

В приложенном файле макро работы с flash. Баг всплывает где-то при переходе с сегмента на сегмент

Прикрепленные файлы

 flash.zip ( 1.04 килобайт ) Кол-во скачиваний: 89

 

[serg_ok]

Без нормального супервизора питания

А встроенный чем плох?

[HARMHARM]

Без нормального супервизора питания

А встроенный чем плох?

В первую очередь тем, что он есть не во всех устройствах.

[rezident]

Ну, без нормального, желательно от TI, супервизора вообще использование MSP весьма чревато :-)

Dog Pawlowa, я не совсем понимаю, какую информацию (в виде лекции, теории, баек?) о надежности/ненадежности устройства с внутрипрограммным изменением Flash вы от меня ожидаете услышать? Я не Иоан Богослов чтобы являть откровения. Надежность устройства зависит от многих факторов, и отнюдь не только от наличия/отсутствия куска кода с программирования Flash. Я высказал лишь свое мнение в каком именно случае для меня предпочтительнее использовать внутреннюю Flash вместо доп. EEPROM. И я не утверждал, что это нужно делать всегда. А надежно это или не очень зависит от конкретной реализации.

[Dog Pawlowa]

Я не Иоан Богослов чтобы являть откровения.

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

[rezident]

Ну если байки вас устроят...
У меня не так уж и много законченных (мелко)серийных проектов на MSP430. Использовал INFO внутренней Flash для хранения пользовательских и/или калибровочных данных лишь в трех из них.
Первый - серия около 300 шт. Использовался MSP430F1121 в управлении двигателем. Без внешнего супервизора, но с одной хитростью - вместо супервизора использовался вход ENABLE LDO (имеющий входной триггер Шмитта) который стоял по питанию MSP430. На входе ENABLE стоял обычный резисторный делитель. По питанию MSP430 был резистор (4,7к) для быстрого разряда конденсаторов при выключении LDO. Без резистора MSP430 не всегда стартовал, т.к. в питание "натекало" от входных цепей. К сожалению партия устройств была изготовлена и связь с заказчиком утеряна. Сколько устройств работают и как - мне не известно. Хотя нареканий в период сдачи устройств заказчику не было. Был правда один ремонт, но связанный с аварийной ситуацией.
Вторая (коммуникационный прибор) около двух десятков устройств на двух типах MSP430 без и с встроенным BOD. MSP430F135 (с супервизором) и MSP430F1232 (в последних образцах супервизор заменил на простую RC+диод). Был один глюк, но он был связан с переполением стека из-за вложенных прерываний, а не с самопроизвольным стиранием Flash
Третья довольно свежая - на MSP430F1132. Устройство тоже связано с управлением двигателем. Без внешнего супервизора, только BOD и внешняя RC-цепь на сбросе. Пока 200 шт., но непонятно сколько из них уже в эксплуатации. Так что заключение делать рано.

[Dog Pawlowa]

Ну если байки вас устроят...

Спасибо, сам факт того, что в управлении двигателя использовался MSP430, уже интересен.
Я в свое время побоялся и сделал на PIC'е, но поскольку последний с трудом поддается программированию , значительная часть функций была решена аппаратно.
А по существу проблемы - о возможности порчи флэш... Соблазн исключить супервизор всегда есть, так как приборы выпускаются тысячами. Пока сдерживает то, что BOD (не помню наверняка, а даташит под рукой сейчас нет) имеет похуже быстродействие, чем супервизор. То есть команда может сбиться, программа "улетит", и до срабатывания WDT натворит дел (сотрет ту же флэш, особенно если код этого стирания есть).
Пожалуй, мне нужно перепроверить новые данные про MSP, в последнее время пришлось заниматься AVRом.

Гроза...
Конечно... Январь, однако...

[Lucky:)]

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

почему MSP430 так "опасен" для работы с мотором?

[el34]

да вроде не опасен... может из-за температурного диапазона?....

[Lucky:)]

да вроде не опасен... может из-за температурного диапазона?....

так у них температурный диапазон вроде не плохой - −40°C to 85°C

[Dog Pawlowa]

почему MSP430 так "опасен" для работы с мотором?

Это скорее мотор "опасен" для работы с MSP. Мотор создает импульсные помехи, которые при отсутствии защиты от них "сбивают" контроллер.
От импульсных помех можно защитить любой контроллер, и MSP в том числе, но встает вопрос цены этой защиты.

[Lucky:)]

Это скорее мотор "опасен" для работы с MSP. Мотор создает импульсные помехи, которые при отсутствии защиты от них "сбивают" контроллер.
От импульсных помех можно защитить любой контроллер, и MSP в том числе, но встает вопрос цены этой защиты.

У MSP430 так чуствительны пины или ритание?

[rezident]

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

почему MSP430 так "опасен" для работы с мотором?

Кто сказал, что опасен? ;) MSP430 чувствителен к EMI ничуть не больше, чем любой другой контроллер. Просто вопросам EMI всегда нужно уделять должное внимание.
Как-то в одном пилотном варианте устройства управления маломощным двигателем трассировщик неправильно по требованиям устойчивости к EMI оттрасировал цепь подключения к MSP430 высокочастотного кварцевого осциллятора. Его корпус и точку соединения конденсаторов обвески осциллятора посадил на "грязную" землю питания. Естественно осциллятор иногда сбоил. Не слишком критично (программа-то не зависала), но были неприятные моменты с управлением. Я адаптировал программу под использование DCO у MSP430. При той же самой схемотехнике, только с кварцем 32768Гц (который использовался только для калибровки DCO) результат по устойчивости работы оказался удовлетворительным. Схему переделали (устранили ошибку с трассировкой кварцевого осциллятора и его обвески), но программу, работающую на DCO оставили. Оказалось, что работа MSP430 на DCO устойчивее, чем с внешним осциллятором. Что впрочем и не удивительно
Насчет

да вроде не опасен... может из-за температурного диапазона?....

могу еще одну байку рассказать. Одному нашему клиенту не понравилось, что партия устройств (в которых применялся в т.ч. MSP430) у нас была в некрашенных алюминиевых корпусах. Они решили покрасить уже готовые устройства. Покрасили. Но по условиям применения краски она требовала сушки в печи. Так что после покраски прогнали все устройства через печь, где грели их до 105-110 градусов несколько часов. Ни одно устройство из более, чем 150 штук после такого издевательства, пока не отказало. MSP430 в этих устройствах естественно были уже запрограммированные. Конечно о надежности Flash в этих "печеных" устройствах можно будет говорить лет через 5-7-10, но факт "жарки" можно зафиксировать уже сейчас.
P.S. Еще одно кстати. Климатику на холод (до -40) устройства на MSP430 проходят нормально. Проблема встречалась лишь на платах без покрытия при испытаниях на "росу".

[HARMHARM]

Подтверждаю - и грели, и замораживали до минус 40. Работают

[jorikdima]

только с кварцем 32768Гц (который использовался только для калибровки DCO)

А расскажите в двух словах, это как?

[Lucky:)]

-40 ... +100C
ОООчень хорошо, что есть реальные свидетели.

только с кварцем 32768Гц (который использовался только для калибровки DCO)

А расскажите в двух словах, это как?

да Rezident, пожалуйста расскажите.

[HARMHARM]

Я, правда, не rezident; но позволю себе ответить. Надеюсь он на меня не обидится
Дело в том, что в MSP430 есть внутренний тактовый RC-генератор DCO, который имеет возможность более-менее точной подстройки частоты битами RSELx, DCOx, MODx. Если ACLK работает от кварца 32768 Гц, то эта система потребляет немного, особенно если использовать кварц еще и для MCLK. А если надо резко ускориться и что-нибудь сделать, то можно включить DCO (заранее подстроенное под нужную частоту), быстренько сделать вычисления, и отключить DCO чтоб не жрал. Правда, надо помнить о том, что частота DCO меняется от температуры, и заранее подстроенная частота может уйти. Все это написано в slau049 в разделе 4.2.4.

Сообщение отредактировал HARMHARM - Jan 15 2007, 10:40

[rezident]

только с кварцем 32768Гц (который использовался только для калибровки DCO)

А расскажите в двух словах, это как?

Чтобы беспричинно "не умножать сущностей" предлагаю почитать какой-нибудь application note на эту тему. Например, slaa074-Controlling the DCO Frequency of the MSP430x11x.
Если вкратце, то DCO (встроенный в MSP430 генератор RC-типа) можно откалибровать, используя внешний осциллятор, путем подсчета (с помощью TimerA) числа импульсов от DCO в створе временнЫх ворот, формируемых от внешнего осциллятора. Естественно, чем больше разница в частотах DCO и осциллятора, тем точнее можно определить эту разницу. Поэтому при частоте DCO 1МГц и более используется часовой кварц 32768Гц. Нужно только не забывать, что
- генератор на часовом кварце стартует весьма медленно (start-up до 1 секунды м.б.);
- DCO (для MSP430x1xx) на унутренних R и C не дает частоты выше (примерно) 6.5МГц. Но при использовании внешнего резистора (Rosc) его можно гнать аж до сотни МГц. Однако при этом ядро MSP430 на такой частоте работать не сможет.
Процедура калибровки (для MSP430x1xx) примерно такова (XT1 в режиме LFXT с кварцем 32768Гц).
1) ждем >1сек после подачи питания.
2) программируем TimerA. Источником его тактирования выбираем SMCLK=DCO. CCR2 таймера TimerA используем в режиме захвата (capture) с источником сигнала от CCI2B (это сигнал ACLK для всех этих кристаллов) и фиксацией по одному из фронтов.
3) по факту срабатывания защелки берем разницу между двумя "соседними" (последовательными) значениями CCR2. Это число (разница) и будет отношением двух частот SMCLK(DCO) и ACLK(32768Гц).
4) если нужно не просто знать значение частоты DCO, но и подогнать его частоту в некоторый диапазон чатот, то манипулируем с битами DCOx, MODx и RSELx регистров DCOCTL и BCSCTL1, а затем переходим снова на шаг 3.

[jorikdima]

ну в общем я так и думал. Спасибо