k155la3 26 7 июня, 2017 Опубликовано 7 июня, 2017 · Жалоба 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 30 7 июня, 2017 Опубликовано 7 июня, 2017 · Жалоба (?) При выполнении этой ф-ии тестовые байты пишутся, но и сегмент при этом стирается. Это вопрос? Ибо 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 5 7 июня, 2017 Опубликовано 7 июня, 2017 · Жалоба прописать несколько байт данных. (не стирая данные по остальным адресам сегмента) Конечно можно. А как вы иначе представляете себе запись всех байтов сегмента, если за один раз можно записать максимум одно слово? Так и пишутся один за другим. Другое дело, если бы вопрос был, можно ли несколько раз писать в один и тот же байт (слово), последовательно меняя различные биты с 1 в 0. Вот тут уже могут быть нюансы исходя из конкретного контроллера. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mcheb 0 7 июня, 2017 Опубликовано 7 июня, 2017 · Жалоба Можно. Но если был записан 0, а надо записать 1 , придётся стереть Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k155la3 26 8 июня, 2017 Опубликовано 8 июня, 2017 (изменено) · Жалоба (1) Это вопрос? .... (2) Ибо SLAU208P стр 344. .... (3) Таких фокусов (по дописи) я не делал, но запись в чистую память от стирания не зависит. (1) Собственно, исходя из чего. Я также (3), в режиме до-пере-записи флеш не исользовал. А со стиранием работает без вопросов. Но давеча начал писать этот код. Думал, "шас" за полчаса сделаем. Параметризация прибора через терминал USART. В нем есть команда ConfigLock, по которой в первый байт сегмента заносится 0x00. При попытке выполнить после этого конфигурирование - он (первый байт) анализируется, и если == 0x00 - то конфигурирование невозможно. А если == 0xFF - то возможна. Такой себе псевдо-FUSE. Сброс - только через стирание контроллера. ------- Так вот, на этапе проверки мой отладчик-программатор начал так чудить, что это пролечилось только стиранием контроллера через Elprotronic. Исходя из этого я и задал вопрос - может чего сделал принципиально не так. Сейчас понятно, что "вроде так", будем искать другие причины в своей епархии. (2) воистну, курите, и откроется Вам :) Конечно можно. . . . . Другое дело, если бы вопрос был, можно ли несколько раз писать в один и тот же байт (слово), последовательно меняя различные биты с 1 в 0. Вот тут уже могут быть нюансы исходя из конкретного контроллера. Спасибо за инф. Да, гдето в док. есть упоминание о возможном повреждении контроллера, в случае последовательной записи в один байт. Сейчас начал раскуривать подробно эту тему. Можно. . . . Ok Спасибо. Изменено 8 июня, 2017 пользователем k155la3 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k155la3 26 8 июня, 2017 Опубликовано 8 июня, 2017 (изменено) · Жалоба Взял пример от 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 } :) =========================== NextStep ============================ После стирания процессора утилитой от Elprotronic - пример от Ti работает и отлаживается по BP без глюков. Сравнение обратно-слитой "глючной" прошивки и ново-залитой после стирания Elprotronic - отличия в CODE нет. различаются только INFO сегменты (что и дожнобыть) ========================= NextStep ====================== Проверил работу с записью "поверх", без стирания - на базе примера от Ti. Все работает. Поскольку глюк наблюдался при отладке в составе рабочего проекта, то скорее всего причина в этом. Там в частности, используется DMA. Но факт в том, что после "влета" процессора в этот сбойный-непонятный режим, не идут нормально даже отсаженные в отдельный проект примеры от Ti. Изменено 8 июня, 2017 пользователем k155la3 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k155la3 26 9 июня, 2017 Опубликовано 9 июня, 2017 · Жалоба ==================== 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 5 9 июня, 2017 Опубликовано 9 июня, 2017 · Жалоба Симптомы проблемы пролечились, когда я структуры, расположенные в INFO-областях передекларировал на __no_init. Вы ни разу не обмолвились, какой у вас компилятор. Для ИАР-а применяйте спец конструкцию такого типа, у меня с ней никогда проблем не было: #pragma segment = "INFOD" #pragma location = "INFOD" __root __ro_placement const volatile config_t ConfigFLASH_1; Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k155la3 26 12 июня, 2017 Опубликовано 12 июня, 2017 · Жалоба . . . какой у вас компилятор. . . . IAR C/C++ Compiler for MSP430 6.40.1.950 ------- __ro_placement - не знал. Спасибо за инф. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
NikolyaN 0 15 июня, 2017 Опубликовано 15 июня, 2017 · Жалоба Тут пришел Ржевский и все опошлил :-) В свое время тоже реализовывал подобную задачу. И байтики можно дописывать и в байтиках битики менять с 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 5 15 июня, 2017 Опубликовано 15 июня, 2017 · Жалоба То есть, как я понимаю это дело. Есть какое-то накапливающееся время подачи программирующего напряжения. При каждой записи байта/слова это время увеличивается. И если оно превысило 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 А если хотите молотить в одни и те же байты без стирания, то тут уж считайте время :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
NikolyaN 0 15 июня, 2017 Опубликовано 15 июня, 2017 · Жалоба Как-то я не вижу связи между двумя вашими абзацами. Суммарное время записи байтов блока до стирания это одно, а надежное изменение параметров во флеши по типу транзакции это совсем другое. Если делать ненадежно, то вполне можно блок читать в ОЗУ и изменять, потом стирать блок флеша и писать из ОЗУ обратно. Так в том и проблема, что насколько я понял, человек хочет дописывать байтики в уже записанный блок. И если суммарное время этих записей превысит tCPT то может произойти большой облом - похерится не только что он пытается записать, но и то что было записано до этого. Хотя я экспериментировал и не смог такого добиться даже переписывая по одному биту меняя из 1 в 0 весь блок. Но флэшь имеет свойство стареть, и при разных температурах результаты могут отличаться. А потом я просто дал человеку совет как сделать это просто и надежно, и не превышать это время. Теперь подумайте, что будет если сделать так как посоветовали вы, если после стирания флэша произойдет какой-то сбой. Вы останетесь без настроек :-). В моем варианте в случае сбоя у вас останутся хотя бы старые настройки. А если хотите молотить в одни и те же байты без стирания, то тут уж считайте время А вот с этим по моему большие проблемы, потому что когда пишется флэш все остальное стопорится (наверняка утверждать не буду, но по экспериментам мне так показалось). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Baser 5 15 июня, 2017 Опубликовано 15 июня, 2017 · Жалоба Так в том и проблема, что насколько я понял, человек хочет дописывать байтики в уже записанный блок. У человека были глюки из-за недопонимания компилятором применяемых объявлений переменных. А дозаписывание байтов в блок - типовая практика. Как я посчитал выше, один раз можно всегда записать по байту. Если писать по слову, уже можно два раза писать: сначала значение, а потом нули. На таком принципе делается хранение параметров в виде структур с индексом параметра и значением. Это для увеличения ресурса флеши, где хранятся параметры. Для STM32 есть такой application note по эмуляции eeprom. Теперь подумайте, что будет если сделать так как посоветовали вы, если после стирания флэша произойдет какой-то сбой. Вы останетесь без настроек Конечно, но для некритичных применений вполне может сгодиться. Знаю у кого так сделано и тысячи приборов по всему миру работают. Ну, слетят иногда настройки пользователя в начальные - техподдержка даже не сильно и напрягается... А вот с этим по моему большие проблемы, потому что когда пишется флэш все остальное стопорится (наверняка утверждать не буду, но по экспериментам мне так показалось). Да, при работе из флеша CPU ожидает завершения. При работе из ОЗУ частично работает. Есть глава в руководстве: Flash Memory Access During Write or Erase Но в данном случае я употребил "считайте время" фигурально, тут достаточно считать кол-во записей во флеш. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
NikolyaN 0 16 июня, 2017 Опубликовано 16 июня, 2017 (изменено) · Жалоба У человека были глюки из-за недопонимания компилятором применяемых объявлений переменных. И еще у человека был вопрос а можно ли вообще так делать. Вот я и предупредил человека, чтобы у него не возникло других глюков. А в зависимости от критичности его приложения пусть сам решает, стоит ему так делать или нет. Я у себя так делать не стал, хотя тестирование показало, что все замечательно переписывается много-много раз и ничего не портится. Изменено 16 июня, 2017 пользователем NikolyaN Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k155la3 26 16 июня, 2017 Опубликовано 16 июня, 2017 · Жалоба Так в том и проблема, что насколько я понял, человек хочет дописывать байтики в уже записанный блок. И если суммарное время этих записей превысит tCPT то может . . . . не привысит :) Я так "закрываю" блок параметров, которые заносятся в прибор при первом запуске и его конфигурировании. т.е. После дозаписи этого байта ( 0x00 ) блок параметров в этом сегменте изменяться уже не будет никогда (только при перезаливке FW). По этому "флаговому" байту разрешается или запрещается ( == 0x00) "вход" в меню начальной параметризации прибора. Вся остальная параметризация (которая будет-может изменяться) хранится во внешнем флеше. Спасибо за инф., в дальнейшем пригодится. У человека были глюки из-за недопонимания компилятором применяемых объявлений переменных. . . . Шас все работает так как надо, (возможно - глюк "затаился", до времени). Я сбойный проект отложил в архиве, будет время - покопаюсь, может найду причину (если это не то, что я приводил выше). Спасибо. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться