1921ВК035 FLASH

[smispp]

Подскажите пожалуйста.

Необходимо сделать виртуальную EEPROM на базе FLASH данного контроллера. В РП туманно написано, или вообще не написано.
1. Какова организация FLASH и минимальный размер ячейки для записи (32 или 64 бит) ?
2. Можно ли записывать, стирать данные в выделенных секторах под EEPROM из кода во FLASH ,
или код должен находится в RAM? Ведь там, в РП, как сказано: Во время записи и стирания, чтение выполняется с неопределенным результатом. А выборка кода программы это же и есть чтение.
3. Значение во FLASH после стирания?
4.Нужно ли отключать КЭШ, чтобы запись реально прошла , и потом опять включать?

[dav]

1. Какова организация FLASH и минимальный размер ячейки для записи (32 или 64 бит) ?
2. Можно ли записывать, стирать данные в выделенных секторах под EEPROM из кода во FLASH ,
или код должен находится в RAM? Ведь там, в РП, как сказано: Во время записи и стирания, чтение выполняется с неопределенным результатом. А выборка кода программы это же и есть чтение.
3. Значение во FLASH после стирания?
4.Нужно ли отключать КЭШ, чтобы запись реально прошла , и потом опять включать?

Доброго времени суток!
1. Размер страницы - 1кБ, Запись осуществляется по 64 бита (два 32-разрядных регистра DATA)
2. Код, осуществляющий запись во Flash должен выполняться из ОЗУ.
3. После стирания во всех ячейках Flash значение 0xFFFFFFFF (все единицы)
4. Запись во Flash осуществляется через регистры, а не через запись в адресное пространство Flash (0000_0000h – 0000_FFFFh).

[smispp]

Доброго времени суток!
1. Размер страницы - 1кБ, Запись осуществляется по 64 бита (два 32-разрядных регистра DATA)
2. Код, осуществляющий запись во Flash должен выполняться из ОЗУ.
3. После стирания во всех ячейках Flash значение 0xFFFFFFFF (все единицы)
4. Запись во Flash осуществляется через регистры, а не через запись в адресное пространство Flash (0000_0000h – 0000_FFFFh).

Спасибо за ответ.

1.почему про пункт 2 в руководстве пользователя даже не упомянуто?
2.почему про пункт 3 в руководстве пользователя ничего не сказано?
3.Но читать из Flash я могу же в обход MFLASH? Хотя во всех примерах, все равно используются интерфейсные функции.
4.Достаточно, чтобы только функции интерфейса MFLASH (конкретно, запись и стирание) лежали в ОЗУ?
Я же не планирую лезть в код программы.
5.Я понимаю что КЭШ трогать не надо, видимо при записи через интерфейс все делается автоматом?

На 1,2 пункт можно не отвечать

[dtolstov]

> почему про пункт 2 в руководстве пользователя даже не упомянуто?
> Но читать из Flash я могу же в обход MFLASH? Хотя во всех примерах, все равно используются интерфейсные функции.
> Достаточно, чтобы только функции интерфейса MFLASH (конкретно, запись и стирание) лежали в ОЗУ?
Я же не планирую лезть в код программы.

В РП на 035 есть абзац про чтение заблокированной памяти. Отсюда следует, что для её перезаписи "на лету" нужно принимать стандартные меры: размещать все нужные функции "драйвера" MFLASH в ОЗУ, блокировать прерывания для предотвращения перехода на таблицу и их обработчики (в недоступной Flash). В общем, посмотрите в реализацию "загрузчика" https://bitbucket.org/niietcm4/k1921vkx ... ot_flash.c

> почему про пункт 3 в руководстве пользователя ничего не сказано?
> Я понимаю что КЭШ трогать не надо, видимо при записи через интерфейс все делается автоматом?

Считайте устройство ПЗУ в первом приближении классической NOR-Flash памятью, как на большинстве кортекс-M микроконтроллеров -- время доступа 30нс, очищенное состояние "единички" 0xFF, ширина слова 64 бит, судя по описанию префетчера. Или пусть разработчики кристалла меня поправят. На диаграмме отображено "64Kx8", а не "8Kx64" -- неужели 8-битная память для 16-битного Тамб-кода?

Read-only кэш I-code и особенно D-code может содержать устаревшие данные после успешной перезаписи MFLASH, но он всё равно инвалидируется через IFLUSH/DFLUSH при последующем его включении заново через ICEN/DCEN, если вы им пользуетесь.

P.S. По поводу идеи "виртуальной EEPROM" рекомендую рассмотреть NVR банк, это ещё 3 страницы по килобайту, если у вас там не хранится загрузчик уже. MFLASH заблокируется в любом случае, ведь в этом кристалле нет выделенной побайтовой EEPROM или (второй ПЗУ) BFLASH.

[smispp]

Спасибо за помощь. Буду изучать.

Read-only кэш I-code и особенно D-code может содержать устаревшие данные после успешной перезаписи MFLASH, но он всё равно инвалидируется через IFLUSH/DFLUSH при последующем его включении заново через ICEN/DCEN, если вы им пользуетесь.

Можете пояснить, в чем разница. Пример пока не смотрел.
Я правильно понимаю? Или чего то не понимаю?
Через шину I-code выбирается программный код.
Через шину D-code выбирается константные данные, которые там можно поместить, и читать через указатель,
как и память, разницы никакой.

1.Если я работаю через интерфейс MFLASH , через какую шину я работаю, может через D-code ?
Опять же в РП описан механизм выборки 2-х слов и помещение их в буфер, затем еще 2-х слов в буфер,
имеется в виду что КЭШ (1к !!! целая страница) выключена? Ведь если КЭШ вклюена, то тогда зачем это описание?

2.влияет ли это на данные КЭШ и в какой КЭШ?

3.что надо делать?
"при последующем его включении заново через ICEN/DCEN, если вы им пользуетесь" - не пользуюсь.

4.в каких случаях надо пользоваться "IFLUSH/DFLUSH "?

P.S. MFLASH заблокируется в любом случае, ведь в этом кристалле нет выделенной побайтовой EEPROM или (второй ПЗУ) BFLASH.

5.Что значит "MFLASH заблокируется в любом случае"?

[dtolstov]

Можете пояснить, в чем разница. Пример пока не смотрел.
Я правильно понимаю? Или чего то не понимаю?
Через шину I-code выбирается программный код.
Через шину D-code выбирается константные данные, которые там можно поместить, и читать через указатель,
как и память, разницы никакой.

1.Если я работаю через интерфейс MFLASH , через какую шину я работаю, может через D-code ?
Опять же в РП описан механизм выборки 2-х слов и помещение их в буфер, затем еще 2-х слов в буфер,
имеется в виду что КЭШ (1к !!! целая страница) выключена? Ведь если КЭШ вклюена, то тогда зачем это описание?

2.влияет ли это на данные КЭШ и в какой КЭШ?

При выборке инструкций из области программ, а это 0x00000000-0x1FFFFFFF, доступ происходит по I-bus через I-cache. Прочитанные инструкции оседают в кэше инструкций.
При выборке данных (.rodata, .data, .bss) из области данных, а это 0x20000000-0x3FFFFFFF, доступ происходит по D-bus через D-cache. Прочитанные данные оседают в кэше данных, записанные данные модифицируют кэш данных и чуть позже модифицируют SRAM (настраивается политикой кэширования (write-back, write-through и проч).
Все остальные адреса сплошного адресного пространства рассматриваемых мк выбираются через S-bus, в том числе периферия и служебные регистры.

1. При записи через регистры MFLASH работа идёт по S-bus безо всяких кэшей. Естественно, при этом возможен доступ к SRAM по I-bus -- откуда-то же исполняться надо.
2. После разблокировки перезаписанной MFLASH в I-cache могла остаться устаревшая копия недавно прочитанных инструкций, если вы разрабатывали самомодифицирующуюся программу, а в D-cache устаревшая копия .rodata и .data, что в общем-то уже не проблема микроконтроллера, а проблема разработчика.

3.что надо делать?
"при последующем его включении заново через ICEN/DCEN, если вы им пользуетесь" - не пользуюсь.

4.в каких случаях надо пользоваться "IFLUSH/DFLUSH "?

3. Ну так если вы не включаете I-Cache Enable и D-Cache Enable, то о чём вы вообще беспокоитесь?

4. IFLUSH надо пользоваться при стороннем изменении бинарного кода программы. DFLUSH надо пользоваться, если эту SRAM наблюдает кто-то ещё, будь то второй процессор или хотя бы DMA-контроллер.

5.Что значит "MFLASH заблокируется в любом случае"?

В смысле случай а) прыжок в SRAM, отключение/блокировка MFLASH, запись MFLASH порегистрово, включение MFLASH обратно
И случай б) прыжок в SRAM, переключение MFLASH с банка основной мегабайтной памяти на EEPROM банк, отключение/блокировка (исполняться оттуда сейчас не будем), запись порегистрово, разблокировка, переключение на основной банк.

[smispp]

Спасибо за подробный ответ. Помогает.

2. После разблокировки перезаписанной MFLASH в I-cache могла остаться устаревшая копия недавно прочитанных инструкций, если вы разрабатывали самомодифицирующуюся программу, а в D-cache устаревшая копия .rodata и .data, что в общем-то уже не проблема микроконтроллера, а проблема разработчика.

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

3. Ну так если вы не включаете I-Cache Enable и D-Cache Enable, то о чём вы вообще беспокоитесь?

самомодифицирующуюся программу не пишу и кэш не включаю, значит не бепокоюсь?

4. DFLUSH надо пользоваться, если эту SRAM наблюдает кто-то ещё, будь то второй процессор или хотя бы DMA-контроллер.

Предположим мы изменили данные и они лежат в кэш. DMA-контроллер лезет и забирает эти новые данные. Или он не работает через кэш, а лезет прямо в память?

В смысле случай а) прыжок в SRAM, отключение/блокировка MFLASH, запись MFLASH порегистрово, включение MFLASH обратно
И случай б) прыжок в SRAM, переключение MFLASH с банка основной мегабайтной памяти на EEPROM банк, отключение/блокировка (исполняться оттуда сейчас не будем), запись порегистрово, разблокировка, переключение на основной банк.

"прыжок в SRAM? отключение/блокировка MFLASH," - То есть если я вызову функцию из SRAM, то почему флэш то заблокируется, когда видимо есть явные механизмы блокировки. Ну не читается из нее в этот момент ничего. Сам термин какой то страшный. И что будет после возврата из функции, то есть получается я должен чего то явно деблокировать. Не понятно.

"переключение MFLASH с банка основной мегабайтной памяти на EEPROM банк" - но ведь это делается специально, и далее сброс. И какое нам дело, что она там где то блокируется, деблокируется?

"запись порегистрово" - вся работа с MFLASH - это работа с регистрами , пишем, читаем, а как можно иначе? Почему надо задумываться о какой то блокировке?

[smispp]

Ознакомился с исходниками BootFlasher. В кодах BootFlasher все расположено в SRAM?

Предыдущий ответ многое прояснил, но Хотелось бы уточнить относительно flash.

В пнкте 7.2 Загрузочная Flash-память РП сказано:
"Загрузочная Flash-память (NVR область) может использоваться для хранения пользовательской программы-загрузчика"
и "При этом обе области полностью доступны для чтения, записи, стирания через регистровый интерфейс MFLASH."

Эту фразу можно понять так, что можно выполнять программу из NVR Flash, и нет нужды держать всю программу в SRAM.
Иначе зачем тогда NVR Flash нужна, если весь (или почти весь) загрузчик лежит в SRAM?

С другой стороны сказано:
"Примечание – параллельный доступ к NVR и основной области Flash-памяти невозможен.
Так например, ядро, исполяющее код из основной области Flash будет вынужденно остановиться
на время осуществления модификации NVR области, т.к. не может в это время считывать инструкции.
Подобное справедливо и для обратного случая"

Тут интересна фраза

"остановиться .... т.к. не может в это время считывать инструкции"

и эта

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

То есть считывать будет, но непонятно что!!!
А если включить I-code кэш, то кусок кода программного опроса занятости Flash будет находится в кэш, и что тогда?
Тогда нет разницы, программа выполняется из РАМ или КЭШ.
Кэш, изначально выключена, я правильно понимаю?

Из всего сказанного следует в SRAM достаточно распологать достаточно небольшой код MFLASH_... функций.
Или включить кэш.

Люди добрые, помогите или опровергните, кто чем может.

[dav]

Ознакомился с исходниками BootFlasher. В кодах BootFlasher все расположено в SRAM?

Доброго времени суток!
В коде загрузчика K1921VKx_Flasher функции записи (стирания) для основной области Flash памяти при старте программы копируются в область RAM памяти контроллера (для этого используется макрос RAMFUNC). Изначально код загрузчика должен храниться в энергонезависимой памяти (код K1921VKx_Flasher изначально записывается в первые 3 страницы NVR область Flash памяти), чтобы не загружать его каждый раз по JTAG. А при старте программы из NVR области Flash памяти после определения через NMI режима загрузчика - переключаемся в режим BootLoaderа, и функции (объявленные через макрос RAMFUNC) копируются в ОЗУ для корректной записи в основную область Flash или же, в случае неактивного состояния вывода NMI, переключаемся на выполнение программы, расположенной в основной области Flash памяти.
В файле README_035.md описана реализация для 1921ВК035, а в файле NOTES.md приводится описание протокола обмена с программой на ПК.

[smispp]

Спасибо за ответ.

То что код из NVR переносится в SRAM понятно. Видимо также как и с инициализируемой памятью. Хотя и не понятно, какая связь между обьявлением секции RAMFUNC в РАМ с переносом кода туда из FLASH . А если бы я создал эту секцию во FLASH , тот что бы было?

Но вы не ответили на другие вопросы. И в частности, достаточно ли держать в SRAM выдачу команды MFLASH и программный цикл проверки занятости , стоящий после выдачи команды?