[jcxz 361]

43 минуты назад, Arlleex сказал:

Нет, тут что-то другое. Вангую, у ТС XMC4xxx, соответственно, Flash там имеет стертое состояние бита там 0, запрограммированное 1.

Функция, видимо, вернет 0 тогда и только тогда, когда все биты в 32 словах флеш запрограммированы, т.е. имеют значение 0xFFFF'FFFF.

Мой код рассчитан на компиляцию либо для XMC4xxx либо для STM32F7xx. Поэтому определён #define PFLASH_CLEAN:

//for XMC4xxx
#define PFLASH_CLEAN        0          //PFLASH bits clean state (0 or 1)

...

//for STM32F7xx
#define PFLASH_CLEAN        1          //PFLASH bits clean state (0 or 1)

а уже функция анализа флеша - универсальна по причине использования PFLASH_CLEAN

Раз уж народу так интересно где это используется, выложу кусок:

//mapWrite[][0] - биткарта страниц, данные в которых должны измениться прошивкой (биткарта меняющихся страниц)
//mapWrite[][1] - биткарта страниц, в которых новая прошивка содержит биты !=PFLASH_CLEAN (биткарта страниц с не_исходным содержимым)
__no_init static u32 mapWrite[PFLASH_SIZE / PFLASH_PAGE_SIZE / 32][2] @ ".noinit"; //один бит на страницу
__no_init static FirmwareHead fwh @ ".noinit";
__no_init static FirmwareHead fwhWrite @ ".noinit";
__no_init static FwDevHdr fdh @ ".noinit";
__no_init static Aes256 aesctx[2] @ ".noinit";
__no_init static Sha256 shactx @ ".noinit";
static u8 rep;


int func()
{
  ...
  u32 j, j1, j2, j3, j4, j5, n, *p, *pa, *pa1;
  u32 mapErase; //биткарта стираемых секторов образа обновления
  u32 mapFW;    //биткарта всех секторов образа обновления
  uint c;
  u8 *s;
  u64 mpu;

  ...

  s = &rb.buf[sizeof(rb.buf) - ACHUNK_L - sizeof(fdh)];
  mapFW = mapErase = j3 = 0;
  do {
    n = ALIGN_UP(pe->size, PFLASH_PAGE_SIZE);
    do {
      memcpy(&rb.buf[sizeof(rb.buf) - ACHUNK_L], s, ACHUNK_L);
      j1 = PFLASH_PAGE_SIZE >> 1;
      fwh.size[0] = j = fwh.size[0] - 1;
      if ((s32)(j = j * PFLASH_PAGE_SIZE - ACHUNK_L) < 0) {
        memcpy(&rb.buf[sizeof(rb.buf) - ACHUNK_L - PFLASH_PAGE_SIZE], pkeys->aesVkt, sizeof(pkeys->aesVkt));
        j1 = PFLASH_PAGE_SIZE - ACHUNK_L >> 1;
        j = 0;
      }
      DflashRead16(FI_OFS + sizeof(fwh) + j, j1, &rb.buf[sizeof(rb.buf) - ACHUNK_L - j1 * 2]);
      Decrypt(PFLASH_PAGE_SIZE);
      shactx.Hash64((u32 const *)&rb.buf[sizeof(rb.buf) - PFLASH_PAGE_SIZE], PFLASH_PAGE_SIZE / SCHUNK_L);
      pa1 = pa = (u32 *)(FW_WORK_BEGIN + PFLASH_BEGIN_C);
      j = fdh.target;
      if (j == FIRMWARE_TARGET_UPDATER || (j == FIRMWARE_TARGET_COMPLEX && pe == &fdh.entity[0])) {
        j1 = (j = bootThis) ^ FW_UPDATER0_BEGIN ^ FW_UPDATER1_BEGIN;
        pa = (u32 *)(j1 + PFLASH_BEGIN_C + PFLASH_PAGE_SIZE);
        pa1 = (u32 *)(j + PFLASH_BEGIN_C + PFLASH_PAGE_SIZE);
      }
      pa = (u32 *)((u8 *)pa + n);
      pa1 = (u32 *)((u8 *)pa1 + n);
      p = (u32 *)(&rb.buf[0] + sizeof(rb.buf));
      c = PFLASH_PAGE_SIZE / 4;
      j4 = j2 = j1 = 0;
      do {
        j2 |= (j5 = *--pa) ^ -PFLASH_CLEAN;
        j4 |= (j = *--p) ^ -PFLASH_CLEAN;
        j1 |= j ^ j5;
        j3 |= j ^ *--pa1 ^ -PFLASH_CLEAN;
      } while (--c);
      j = ((u32)pa - PFLASH_BEGIN_C) / PFLASH_PAGE_SIZE;
      if (j4) mapWrite[j >> 5][1] |= 1 << (j & 31);
      mapFW |= j4 = 1u << (u32)PflashSecNum(j * PFLASH_PAGE_SIZE);
      if (j1) {
        mapWrite[j >> 5][0] |= 1 << (j & 31);
        if (j2) mapErase |= j4;
      }
      s = &rb.buf[sizeof(rb.buf) - ACHUNK_L - PFLASH_PAGE_SIZE];
    } while (n -= PFLASH_PAGE_SIZE);
  } while (--pe != &fdh.entity[0] - 1);
...

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

Цикл декриптует и на лету сравнивает содержимое новой прошивки (лежащей в SPI-флешке) с содержимым program-FLASH (в некоторых случаях - содержимым сразу двух областей program-flash). В результате анализа создаются карты стираемых секторов, записываемых страниц и перезаписываемых страниц. Чтобы потом выполнить все операции за один проход и с минимальным количеством стираний/записей флешь (не писать то, что можно не писать и не стирать то, что можно не стирать).

[artemkad 179]

11 минут назад, Arlleex сказал:

Вы уже много раз убеждались, что GCC компилит сильно лучше, чем IAR. Почему нет желания банально перейти на него?

Наверное потому, что есть куча кода написанного под IAR, а переход под GCC это перестройка всей среды, переписывание кода или иначе говоря куча затраченного времени и денег. 

[Arlleex 333]

8 минут назад, artemkad сказал:

Наверное потому, что есть куча кода написанного под IAR, а переход под GCC это перестройка всей среды, переписывание кода или иначе говоря куча затраченного времени и денег. 

Наверное. Но я же не про радикальное удаление IAR с компа навсегда)) Я про начинание очередного нового проекта с чистого листа, так сказать.

15 минут назад, jcxz сказал:

(не писать то, что можно не писать и не стирать то, что можно не стирать).

Ясно. Ресурс экономите (и время).

Я для себя, когда задавался таким вопросом, выбрал синюю таблетку приоритетом ~ одинаковую равномерность износа флешки при обновлении ПО. Я еще читал что-то про некое время удержания данных в прошитой ячейке. Типа, оно не бесконечное, и заряд там как-то рассасывается и бит может с 0 на 1 поменяться (на стертое). Уж пусть все страницы будут прожжены заново и срок их годности будет примерно одинаковым))) А то вдруг когда-нибудь так окажется, что одну из страниц лет 10 не обновляли, а все остальные обновляли)

[jcxz 361]

40 минут назад, Arlleex сказал:

Вы уже много раз убеждались, что GCC компилит сильно лучше, чем IAR. Почему нет желания банально перейти на него?

Перейти на что?

IAR - это не только компилятор, но и отладчик и IDE. А вот это (кроме компилятора) у него как раз хороши. А что есть лучше чем IAR? VSCode??? Да лучше застрелиться чем на него переходить!  

40 минут назад, Arlleex сказал:

Вас, вроде, не покусают за это, ведь свободное бесплатное ПО, вроде как... А то я со стороны как посмотрю, так кажется, что IAR давно уже команда дилетантов пилит, т.к. банальные оптимизации не оптимизирует, грузится долго, заставляет бояться сменить версию (вдруг чего поломается) и т.д.

Кто боится сменить? Я вроде не боялся... И иногда меняю. В самом первом сообщении темы писал про v9.20.4

И "долго грузится" старый IAR v7.80.4. Более новые версии - быстро.

40 минут назад, Arlleex сказал:

Это лет 15 назад GCC под ARM в каких-то частных ситуациях сильно проигрывал IAR. Сейчас времена поменялись, и GCC зализал раны. Или Keil/Clang

Если бы можно было к IAR-у прикрутить GCC в качестве компилятора. А всё остальное - оставить как есть.....  

26 минут назад, artemkad сказал:

Наверное потому, что есть куча кода написанного под IAR, а переход под GCC это перестройка всей среды, переписывание кода или иначе говоря куча затраченного времени и денег. 

Это не большая проблема. Просто не на что переходить.

24 минуты назад, Arlleex сказал:

Ясно. Ресурс экономите (и время).

Код был написан много лет назад. И кочует из проекта в проект. С одного МК на другой.

Экономия времени кстати существенная - на XMC4xxx длительность стирания страниц флеши может достигать 5 секунд (или даже немного больше).

[Arlleex 333]

6 минут назад, jcxz сказал:

Перейти на что?

Keil?

Цитата

IAR - это не только компилятор, но и отладчик и IDE. А вот это (кроме компилятора) у него как раз хороши.

Когда писал прошивку под STM8, для себя определил IAR-овскую IDE как одну из самых примитивных и топорных)) И не удобных. Про отладчик не скажу, не знаю. Но ежели там J-Link какой-нибудь - то в Keil он тоже поддерживается. Хотя я не считаю Keil-овский IDE лучше IAR - то еще дно. Но мне IDE без разницы в основном, т.к. проект пишу в Sublime, в нем есть все что мне нужно для навигации по коду.

[jcxz 361]

34 минуты назад, Arlleex сказал:

Уж пусть все страницы будут прожжены заново и срок их годности будет примерно одинаковым))) А то вдруг когда-нибудь так окажется, что одну из страниц лет 10 не обновляли, а все остальные обновляли)

Советую когда-нить попробовать XMC4xxx. О многих вещах постоянные пользователи STM32 даже не догадываются.  

В API программирования флешь XMC4xxx есть даже признаки качества программирования бит. Есть признаки наличия плохо запрограммированных бит и плохо стёртых. И возможность повторного допрограммирования. И мой тот код и это тоже использует и анализирует.  

7 минут назад, Arlleex сказал:

Keil?

Отпадает. У нас не РФ - ПО лицензионное. IAR - лицензионный уже много лет как.

7 минут назад, Arlleex сказал:

Когда писал прошивку под STM8, для себя определил IAR-овскую IDE как одну из самых примитивных и топорных))

Не знаю. Может дело привычки. Использовал IAR для ARM, для STM8 и для MSP430.. Единство стиля - это огромный ПЛЮСИЩЕ, когда приходится прыгать туда-сюда.

[Arlleex 333]

Только что, jcxz сказал:

Советую когда-нить попробовать XMC4xxx. О многих вещах постоянные пользователи STM32 даже не догадываются.  

То, что там ECC есть? Если так - то и в STM-ках оно есть.
 

Цитата

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

Для меня это все выглядит как "приколюха ради приколюхи". Т.е. экономический/функциональный эффект для конечного пользователя (меня) от этой фичи против ее остуствия в других МК будет равен 0, потому что если встроенный ECC не может исправить ошибку, то девайс в любом случае на реабилитацию. Все эти признаки наличия плохо запрограммированных бит пригодятся, скорее всего, никогда, ИМХО

10 минут назад, jcxz сказал:

Отпадает. У нас не РФ - ПО лицензионное. IAR - лицензионный уже много лет как.

Ну дык купить лицензию Keil.

20 минут назад, jcxz сказал:

Перейти на что?

А вот опять же - что конкретно останавливает?

Например, GCC + Eclipse + J-Link (вроде, его можно подключить к GDB). Что еще нужно для счастья? Segger-овский J-Trace?

[jcxz 361]

16 минут назад, Arlleex сказал:

То, что там ECC есть? Если так - то и в STM-ках оно есть.

Не ECC (хотя оно тоже есть), а признаки качества программирования бит. Как я их понял - полезны как раз в той ситуации, о которой вы писали (почему я и упомянул что вам нужно расширить кругозор      :

54 минуты назад, Arlleex сказал:

Я еще читал что-то про некое время удержания данных в прошитой ячейке. Типа, оно не бесконечное, и заряд там как-то рассасывается и бит может с 0 на 1 поменяться (на стертое)

Грубо говоря - в XMC4xxx программа может иногда проверять качество программирования флеши и уровень разряда ячеек и подзаряжать (подпрограммировать сама себя) если заряд утёк.

Цитата

8.4.9.2 Margin Checks

The Flash memory offers a “margin check feature”: the limit which defines if a Flash cell
is read as logic ‘0’ or logic ‘1’ can be shifted. This is controlled by the register MARP. The
Margin Control Register MARP is used to change the margin levels for read operations
to find problematic array bits. The array area to be checked is read with more restrictive
margins. “Problematic” bits will result in a single or double-bit error that is reported to the
CPU by an error interrupt or a bus error trap. The double-bit error trap can be disabled
for margin checks and also redirected to an error interrupt.

И есть 5-уровневое поле настройки качества маржи ячеек.  также есть прерывания одиночных и двойных ошибок флешь.

Вот это я и имел в виду, когда говорил, что многих вещах постоянные юзеры STM32 даже не догадываются.  

ECC в XMC кстати есть для абсолютно всей памяти - и флешь и ОЗУ и даже различного FIFO в во всей периферии. В STM32 есть такое?

 

16 минут назад, Arlleex сказал:

Для меня это все выглядит как "приколюха ради приколюхи". Т.е. экономический/функциональный эффект для конечного пользователя (меня) от этой фичи против ее остуствия в других МК будет равен 0, потому что если встроенный ECC не может исправить ошибку, то девайс в любом случае на реабилитацию. Все эти признаки наличия плохо запрограммированных бит пригодятся, скорее всего, никогда, ИМХО

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

Деградация от времени вроде как не грозит XMC4....

[Arlleex 333]

16 минут назад, jcxz сказал:

ECC в XMC кстати есть для абсолютно всей памяти - и флешь и ОЗУ и даже различного FIFO в во всей периферии. В STM32 есть такое?

ECC Flash есть, RAM тоже есть. Насчет ECC FIFO в периферии - не знаю, не уверен, что есть. Но и не уверен, что оно туда надо, если честно. Потому что это уже что-то для параноиков, просматривается что-то болезненное)) В реальности супернадежность будет обеспечиваться несколько другими способами, ИМХО. Всякие резервы, дублирования, хот-свапы, мониторинг внешним наблюдатлем и т.д. Т.е. на внутренности одного МК все равно полагаться не станут

[artemkad 179]

1 час назад, Arlleex сказал:

Но я же не про радикальное удаление IAR с компа навсегда))

Это что-то поменяет?

1 час назад, Arlleex сказал:

Я про начинание очередного нового проекта с чистого листа, так сказать.

Чаще всего проекты не пишутся с нуля, а используют в той или иной степени уже имеющийся код. С чистого листа пишут студенты ну или проект типа "Здравствуй мир"

[Arlleex 333]

1 минуту назад, artemkad сказал:

Это что-то поменяет?

Чаще всего проекты не пишутся с нуля, а используют в той или иной степени уже имеющийся код.

Если код написан без кучи implementation-зависимых вещей, то даже перетаскивание написанного 100500 лет назад кода не составит труда.

[jcxz 361]

37 минут назад, Arlleex сказал:

Ну дык купить лицензию Keil.

37 минут назад, Arlleex сказал:

Например, GCC + Eclipse + J-Link (вроде, его можно подключить к GDB). Что еще нужно для счастья? Segger-овский J-Trace?

Eclipse??!   Лучше пусть IAR даже ещё в 5 раз хуже код компилит! 

 

PS: Лучше подскажите - как IAR-у подсунуть GCC-компилятор вместо своего родного? Чтобы всё остальное осталось как было, а компиляция стала GCC-шной.

В Кейле вроде такое возможно я слышал?

2 минуты назад, Arlleex сказал:

Если код написан без кучи implementation-зависимых вещей, то даже перетаскивание написанного 100500 лет назад кода не составит труда.

вот именно. Исключение  главным образом - ассемблер. Да и то - решаемо.

[Arlleex 333]

Только что, jcxz сказал:

Eclipse??!   Лучше пусть IAR даже ещё в 5 раз хуже код компилит! 

😄

Цитата

В Кейле вроде такое возможно я слышал?

Не знаю о подобном. Но даже и задумываться не приходилось - не было надобности.

[VladislavS 46]

IAR хорош как законченный инструмент. Он умеет абсолютно всё из коробки, каждый шаг подробно описан в документации, которая тут же и лежит. От линкерскриптов до макросов отладчика и алгоритмов прошивки чипов. Ну и отладчик отличный. За это можно ему допотопный редактор простить. Тем кто в нём плотно не работал трудно это всё объяснить. За частую, вся критика оканчивается словами "убогий редактор". У Keil он тогда вообще днище. Жаль, только, что эта идилия заканчивается когда надо работать с чем-то отличным от ARM.

9 часов назад, jcxz сказал:

не писать то, что можно не писать и не стирать то, что можно не стирать

А потом вспоминаешь про 100K циклов записи и смену прошивки несколько раз в год в первые пару лет эксплуатации и становится грустно 😅

[jcxz 361]

50 минут назад, VladislavS сказал:

IAR хорош как законченный инструмент. Он умеет абсолютно всё из коробки, каждый шаг подробно описан в документации, которая тут же и лежит.

Это точно. А ещё в нём "из коробки" есть куча примеров проектов работающего кода под разные МК. Которые только поставив IAR, можно сразу скомпилить и запустить на отладке.

Не надо лазить по инетику и искать всякие сомнительного качества примеры.

Поэтому - он хороший выбор для новичков.

49 минут назад, VladislavS сказал:

А потом вспоминаешь про 100K циклов записи

Вы это не попутали с МК с FRAM-памятью?     Или с EEPROM...

100К - это ещё поискать такие надо. А в типичных МК: 1...10 тыс. циклов. Всего-то на 2 порядка хватанули!  

А в некоторых случаях - и того меньше. Например - установка/снятие защиты flash на XMC4xxx - всего 20 раз можно. Не 20тыс., а просто 20 (если склероз не изменяет). А потом - на перепайку МК.

49 минут назад, VladislavS сказал:

и смену прошивки несколько раз в год в первые пару лет эксплуатации и становится грустно 😅

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

А моя процедура - она написана всего один раз. А потом просто переносится с одного проекта в другой. Затраты небольшие, а профит всегда есть.

 

PS: И как выше писал - моя процедура ещё и существенно сокращает время обновления прошивки. Если вспомнить, что иногда только стирание одного сектора флешь может идти более 5 сек, это бывает существенно.