MSP430F5438A запись в INFO-D без стирания, Возможна ли запись байта без стирания сегмента Опции

[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;
}

[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]

Симптомы проблемы пролечились, когда я структуры, расположенные в INFO-областях передекларировал на __no_init.

Вы ни разу не обмолвились, какой у вас компилятор.
Для ИАР-а применяйте спец конструкцию такого типа, у меня с ней никогда проблем не было:

Код

#pragma segment = "INFOD"
#pragma location = "INFOD"
__root __ro_placement const volatile config_t ConfigFLASH_1;

[k155la3]

. . . какой у вас компилятор. . . .

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]

То есть, как я понимаю это дело. Есть какое-то накапливающееся время подачи программирующего напряжения. При каждой записи байта/слова это время увеличивается. И если оно превысило 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]

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

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

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

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