Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: MSP430F5438A запись в INFO-D без стирания
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > MSP430
k155la3
MSP430F5438A
Работа с INFO-D флеш сегментом.
Задача - в заполненном иноформацией INFO-D поверх незаписанных байт по фиксированным адресам (содержащим == 0xFF )
прописать несколько байт данных. (не стирая данные по остальным адресам сегмента)

Примеры Ti представлены все со стиранием сегмента.

(?) При выполнении этой ф-ии тестовые байты пишутся, но и сегмент при этом стирается.
Допустим ли в принципе такой режим (не в формате ERASE+WRITE, а только WRITE) ?

Ф-ия выполняется из флеш-памяти.

Код
#define FLASH_BUSY 0x0001
#define FLASH_LOCK 0x0010
void INF_Lock( void )
{
    Flash_ptr = (char *) 0x1800; // INFO-D

    __disable_interrupt();

    FCTL3 = FWKEY;                            // Clear Lock bit
    FCTL1 = FWKEY + WRT;                         // Enable byte/word write mode

    //while ( (FCTL3 & FLASH_BUSY ) != 0 );     // test busy - для RAM
    *Flash_ptr = 0xAB;

     Flash_ptr++;

     //while ( (FCTL3 & FLASH_BUSY ) != 0 );     // test busy
     *Flash_ptr = 0xCD;

     FCTL1 = FWKEY;                                 // Clear WRT bit
     FCTL3 = FWKEY + FLASH_LOCK;           // Set LOCK bit

    __enable_interrupt();

    return;
}




Obam
Цитата
(?) При выполнении этой ф-ии тестовые байты пишутся, но и сегмент при этом стирается.

Это вопрос?
Ибо SLAU208P стр 344.
7.2 Flash Memory Segmentation
The flash main memory is partitioned into 512-byte segments. Single bits, bytes, or words can be written
to flash memory, but a segment is the smallest size of the flash memory that can be erased. подчёркнуто мной
Опять же стр 351 7.3.2.2 Initiating Byte or Word Write From Flash и пример, а стирание самостоятельным параграфом.

Таких фокусов (по дописи) я не делал, но запись в чистую память от стирания не зависит.
Baser
Цитата(k155la3 @ Jun 7 2017, 16:37) *
прописать несколько байт данных. (не стирая данные по остальным адресам сегмента)

Конечно можно. А как вы иначе представляете себе запись всех байтов сегмента, если за один раз можно записать максимум одно слово? Так и пишутся один за другим.

Другое дело, если бы вопрос был, можно ли несколько раз писать в один и тот же байт (слово), последовательно меняя различные биты с 1 в 0. Вот тут уже могут быть нюансы исходя из конкретного контроллера.
mcheb
Можно. Но если был записан 0, а надо записать 1 , придётся стереть
k155la3
Цитата(Obam @ Jun 7 2017, 17:31) *
(1) Это вопрос?
....
(2) Ибо SLAU208P стр 344.
....
(3) Таких фокусов (по дописи) я не делал, но запись в чистую память от стирания не зависит.


(1) Собственно, исходя из чего. Я также (3), в режиме до-пере-записи флеш не исользовал.
А со стиранием работает без вопросов.
Но давеча начал писать этот код. Думал, "шас" за полчаса сделаем.
Параметризация прибора через терминал USART.
В нем есть команда ConfigLock, по которой в первый байт сегмента заносится 0x00.
При попытке выполнить после этого конфигурирование - он (первый байт) анализируется, и если == 0x00 - то конфигурирование невозможно.
А если == 0xFF - то возможна. Такой себе псевдо-FUSE. Сброс - только через стирание контроллера.
-------
Так вот, на этапе проверки мой отладчик-программатор начал так чудить, что это пролечилось только стиранием контроллера через Elprotronic.
Исходя из этого я и задал вопрос - может чего сделал принципиально не так.
Сейчас понятно, что "вроде так", будем искать другие причины в своей епархии.

(2) воистну, курите, и откроется Вам sm.gif


Цитата(Baser @ Jun 7 2017, 18:25) *
Конечно можно. . . . .
Другое дело, если бы вопрос был, можно ли несколько раз писать в один и тот же байт (слово), последовательно меняя различные биты с 1 в 0. Вот тут уже могут быть нюансы исходя из конкретного контроллера.

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



Цитата(mcheb @ Jun 7 2017, 19:38) *
Можно. . . .

Ok Спасибо.
k155la3
Взял пример от Ti без изменений (там где прописывается INFO-C инкриментом, и копируется INFO-C -> INFO-D) - но все равно не работает.
Гипотезы пока следующие:
- убил процессор (F5438A, rev.F)
- непонятная работа компилятора-отладчика.

Характерный симтом:
После прохода программы и остановки ее в BP на завершающем while(1) (как советует Ti в комментарии)
1. невозможно по Debug->Reset выйти в начало main().
После этого:
2. выхожу из режима Debug, отключаю (проводом) программатор, снимаю питание (и закорачиваю линии питания) с платы F5438A.
Включаю все "обратно".
3. Компилирую проет через "Clean". Загружаю в F5438A.
(Грузится. Стартовая зеленая полоска - на первом операторе main() )
4. Стартуем F5.
Нет останова на последнем холостом while() на BP.
Выполняю Debug->Break. Останов есть, и как раз на __no_operation() на котором стоит BP в while(1).
5. Смотрим View->Memory Info-C Info-D
В Info-C - пусто (0xFF) , хотя дожно быть значение инкримента.
В Info-D - какаято мешанина из частично правильных значений (инкримент=номеру байта в сегменте) .
"Мешанина" имеет регулярную повторяющуюся структуру "b2 40 40 A5".
-------------------

В общем,
A: попробуем поменять процессор. И компилятор.
B: while(1) { slau208, slaz290, slaa470 } sm.gif

=========================== NextStep ============================
После стирания процессора утилитой от Elprotronic - пример от Ti работает и отлаживается по BP
без глюков. Сравнение обратно-слитой "глючной" прошивки и ново-залитой после стирания Elprotronic - отличия в CODE нет.
различаются только INFO сегменты (что и дожнобыть)



========================= NextStep ======================

Проверил работу с записью "поверх", без стирания - на базе примера от Ti. Все работает.

Поскольку глюк наблюдался при отладке в составе рабочего проекта, то скорее всего причина в этом.
Там в частности, используется DMA. Но факт в том, что после "влета" процессора в этот сбойный-непонятный режим,
не идут нормально даже отсаженные в отдельный проект примеры от Ti.
k155la3
==================== NextStep ================
Симптомы проблемы пролечились, когда я структуры, расположенные в INFO-областях передекларировал на __no_init.
( FIELD_1 расположено в INFO )
Код
_root const TMystruct Mystuct @ "FIELD_1" = { 1,2,3, . . . };

переделано на
Код
_root  _no_init  TMystruct Mystuct @ "FIELD_1";

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

Baser
Цитата(k155la3 @ Jun 9 2017, 13:19) *
Симптомы проблемы пролечились, когда я структуры, расположенные в INFO-областях передекларировал на __no_init.

Вы ни разу не обмолвились, какой у вас компилятор.
Для ИАР-а применяйте спец конструкцию такого типа, у меня с ней никогда проблем не было:
Код
#pragma segment = "INFOD"
#pragma location = "INFOD"
__root __ro_placement const volatile config_t ConfigFLASH_1;

k155la3
Цитата(Baser @ Jun 9 2017, 14:40) *
. . . какой у вас компилятор. . . .

IAR C/C++ Compiler for MSP430 6.40.1.950
-------
__ro_placement - не знал.
Спасибо за инф.
NikolyaN
Тут пришел Ржевский и все опошлил :-)
В свое время тоже реализовывал подобную задачу. И байтики можно дописывать и в байтиках битики менять с 1 на 0. И все это замечательно работало. Но от использования в коммерческом проекте меня остановил один абзац в SLAU208:
Цитата
7.3.2.1 Byte or Word Write
...
In any write mode, the internally-generated programming voltage is applied to the complete 128-byte
block. The cumulative programming time, tCPT, must not be exceeded for any block. Each byte, word, or
long-word write adds to the cumulative program time of a segment. If the maximum cumulative program
time is reached or exceeded, the segment must be erased. Further programming or using the data returns
unpredictable results (see the device-specific data sheet for specifications).

То есть, как я понимаю это дело. Есть какое-то накапливающееся время подачи программирующего напряжения. При каждой записи байта/слова это время увеличивается. И если оно превысило tCPT (можно посмотреть в даташите на кристалл) то результат становится непредсказуемым.
В итоге было реализовано поочередная запись в 2 сегмента. В сегменте выделен специальный байт в качестве флага. Сначала этот флаг ставится в состояние что данные устарели, потом новые настройки пишутся в другой сегмент, проверяется правильность записи и только потом сегмент со старыми настройками стирается.
Baser
Цитата(NikolyaN @ Jun 15 2017, 14:43) *
То есть, как я понимаю это дело. Есть какое-то накапливающееся время подачи программирующего напряжения. При каждой записи байта/слова это время увеличивается. И если оно превысило tCPT (можно посмотреть в даташите на кристалл) то результат становится непредсказуемым.

В итоге было реализовано поочередная запись в 2 сегмента...

Как-то я не вижу связи между двумя вашими абзацами. Суммарное время записи байтов блока до стирания это одно, а надежное изменение параметров во флеши по типу транзакции это совсем другое. Если делать ненадежно, то вполне можно блок читать в ОЗУ и изменять, потом стирать блок флеша и писать из ОЗУ обратно.

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

Для примера, серия MSP430F2xx:
блок 64 байт, Cumulative program time 10 ms,
Flash timing generator frequency 257 - 476 kHz
Word or byte program time 30 циклов

Если будете записывать блок на минимальной скорости 257 кГц по одному байту, получиться:
1/257 * 30 * 64 = 7.5 ms < 10 ms

А если хотите молотить в одни и те же байты без стирания, то тут уж считайте время sm.gif
NikolyaN
Цитата
Как-то я не вижу связи между двумя вашими абзацами. Суммарное время записи байтов блока до стирания это одно, а надежное изменение параметров во флеши по типу транзакции это совсем другое. Если делать ненадежно, то вполне можно блок читать в ОЗУ и изменять, потом стирать блок флеша и писать из ОЗУ обратно.


Так в том и проблема, что насколько я понял, человек хочет дописывать байтики в уже записанный блок. И если суммарное время этих записей превысит tCPT то может произойти большой облом - похерится не только что он пытается записать, но и то что было записано до этого. Хотя я экспериментировал и не смог такого добиться даже переписывая по одному биту меняя из 1 в 0 весь блок. Но флэшь имеет свойство стареть, и при разных температурах результаты могут отличаться.
А потом я просто дал человеку совет как сделать это просто и надежно, и не превышать это время. Теперь подумайте, что будет если сделать так как посоветовали вы, если после стирания флэша произойдет какой-то сбой. Вы останетесь без настроек :-). В моем варианте в случае сбоя у вас останутся хотя бы старые настройки.

Цитата
А если хотите молотить в одни и те же байты без стирания, то тут уж считайте время

А вот с этим по моему большие проблемы, потому что когда пишется флэш все остальное стопорится (наверняка утверждать не буду, но по экспериментам мне так показалось).
Baser
Цитата(NikolyaN @ Jun 15 2017, 16:46) *
Так в том и проблема, что насколько я понял, человек хочет дописывать байтики в уже записанный блок.

У человека были глюки из-за недопонимания компилятором применяемых объявлений переменных.

А дозаписывание байтов в блок - типовая практика. Как я посчитал выше, один раз можно всегда записать по байту. Если писать по слову, уже можно два раза писать: сначала значение, а потом нули. На таком принципе делается хранение параметров в виде структур с индексом параметра и значением. Это для увеличения ресурса флеши, где хранятся параметры. Для STM32 есть такой application note по эмуляции eeprom.

Цитата
Теперь подумайте, что будет если сделать так как посоветовали вы, если после стирания флэша произойдет какой-то сбой. Вы останетесь без настроек

Конечно, но для некритичных применений вполне может сгодиться. Знаю у кого так сделано и тысячи приборов по всему миру работают. Ну, слетят иногда настройки пользователя в начальные - техподдержка даже не сильно и напрягается... biggrin.gif

Цитата
А вот с этим по моему большие проблемы, потому что когда пишется флэш все остальное стопорится (наверняка утверждать не буду, но по экспериментам мне так показалось).

Да, при работе из флеша CPU ожидает завершения. При работе из ОЗУ частично работает.
Есть глава в руководстве: Flash Memory Access During Write or Erase

Но в данном случае я употребил "считайте время" фигурально, тут достаточно считать кол-во записей во флеш.
NikolyaN
Цитата(Baser @ Jun 15 2017, 18:36) *
У человека были глюки из-за недопонимания компилятором применяемых объявлений переменных.

И еще у человека был вопрос а можно ли вообще так делать. Вот я и предупредил человека, чтобы у него не возникло других глюков.
А в зависимости от критичности его приложения пусть сам решает, стоит ему так делать или нет. Я у себя так делать не стал, хотя тестирование показало, что все замечательно переписывается много-много раз и ничего не портится.
k155la3
Цитата(NikolyaN @ Jun 15 2017, 16:46) *
Так в том и проблема, что насколько я понял, человек хочет дописывать байтики в уже записанный блок. И если суммарное время этих записей превысит tCPT то может
. . . .

не привысит sm.gif
Я так "закрываю" блок параметров, которые заносятся в прибор при первом запуске и его конфигурировании.
т.е. После дозаписи этого байта ( 0x00 ) блок параметров в этом сегменте изменяться уже не будет никогда (только при перезаливке FW).
По этому "флаговому" байту разрешается или запрещается ( == 0x00) "вход" в меню начальной параметризации прибора.
Вся остальная параметризация (которая будет-может изменяться) хранится во внешнем флеше.

Спасибо за инф., в дальнейшем пригодится.





Цитата(Baser @ Jun 15 2017, 18:36) *
У человека были глюки из-за недопонимания компилятором применяемых объявлений переменных.
. . .


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

Спасибо.

Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2024 Invision Power Services, Inc.