[Arlleex 320]

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

В чём именно "проблемы"?

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

Цитата

Во многих случаях отладка во флешь превращается в сущий кошмар.

Тайна, покрытая мраком. Чего кошмарного? Вы по 100 раз в минуту в отладку заходите выходите?

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

В смысле - полностью или для определённого региона?

Полностью, да.

[sasamy 10]

1 hour ago, jcxz said:

Отладка в ОЗУ - намного удобнее.

 Не проще в симуляторе отлаживать ?

[jcxz 350]

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

Тайна, покрытая мраком. Чего кошмарного?

Только один пример:

Вот например вы ищете баг. Непонятно где он происходит. Поэтому - выставляете кучу бряков в разных подозрительных местах. Больше максимального количества аппаратных бряков, поддерживаемых вашим эмулятором. Сработал один бряк; остановились; хотите прошагать отладчиком несколько строк кода; жмёте кнопку "Step" и... контроллер зависает на 10+ секунд (или больше). Потому как - стирает/перепрограммирует флешь чтобы поставить/снять все поставленные программные бряки. Ведь время стирания сектора флешь = up to 5 секунд (или больше). И так - при каждом шаге по коду! А ещё - такое же зависание при каждой остановке на бряке (снимает бряки) и при новом запуске (ставит бряки).

Как вам такая "отладка"? По 10+ секунд на один шаг? Конкретный кошмар!

А отладка в ОЗУ работает всегда быстро. Сколько бы бряков не стояло.

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

Вы по 100 раз в минуту в отладку заходите выходите?

В том числе и вход в отладку в ОЗУ - кратно быстрее. Меня бесит, когда при отладке ПО приходится при каждой новой загрузке ждать по ~полминуты. Если вам это нравится - выбор ваш.

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

Не проще в симуляторе отлаживать ?

Это не отладка.

[EdgeAligned 136]

Отладка в ОЗУ - это хорошо и даже классно. Но какой смысл пытаться писать в несуществующую область памяти, если обратно прочитать корректные данные нельзя? Это для "один раз побаловаться", как мне кажется.

Во-вторых, для отладки в ОЗУ целесообразно использовать отдельный регион памяти, тот, который CCM или ITCM. Чтобы извлекаемые инструкции не тормозили ЦП. .Я лично наблюдал такой эффект тормозов. 

Если же нужна фейковая запись в несуществующую физически память, можно настроить модуль FSMC/FMC без подключения физической памяти и даже без настроек GPIO. Запись и чтение корректно, без HF работает, только прочитанные данные будут недействительны.

[sasamy 10]

10 minutes ago, jcxz said:

Это не отладка.

это как раз отладка

https://renode.io/about/

а запись/чтение в неопределенные адреса на реальном железе это безвыигрышная лотерея 

[Arlleex 320]

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

Только один пример:

Вот например вы ищете баг. Непонятно где он происходит. Поэтому - выставляете кучу бряков в разных подозрительных местах. Больше максимального количества аппаратных бряков, поддерживаемых вашим эмулятором. Сработал один бряк; остановились; хотите прошагать отладчиком несколько строк кода; жмёте кнопку "Step" и... контроллер зависает на 10+ секунд (или больше). Потому как - стирает/перепрограммирует флешь чтобы поставить/снять все поставленные программные бряки. Ведь время стирания сектора флешь = up to 5 секунд (или больше). И так - при каждом шаге по коду! А ещё - такое же зависание при каждой остановке на бряке (снимает бряки) и при новом запуске (ставит бряки).

Как вам такая "отладка"? По 10+ секунд на один шаг? Конкретный кошмар!

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

[jcxz 350]

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

Про механизм Flash Patch я в курсе, но повторюсь, 6 аппаратных точек при вменяемой локализации уже вполне достаточно.

Ну - во-первых: не 6, а только 5 (один похоже резервируется IAR для каких-то своих целей). Во-вторых: алгоритмы бывают разными. А насчёт штатных программных ловушек: их ещё написать надо; и отладить. А если известно, что баг может возникать в ограниченном ряде мест: то хоть 20 бряков можно поставить - отладка в ОЗУ это позволяет. А вот вы уже начали придумывать обходные пути - как добиться того же во флешь.  В ОЗУ даже проблема такая не возникнет.

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

у названного МК начало флешки чуть дробленое, код можно разместить туда, поэтому никаких 10 секунд там не будет.

Пример был не для "названного МК", а для другого. Если есть разные проекты на разных МК, то лучше поступать похожим образом везде.

 

И я же написал: Это только один из примеров. Есть и другие.

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

Да и ресурс флеши - не бесконечен.

 

PS: В любом случае тема - не про отладку в ОЗУ. оффтопик.

[VladislavS 46]

А  тупо запись во flash без разблокировпния её реальной записи?

[Anxigeros 2]

4 часа назад, VladislavS сказал:

А  тупо запись во flash без разблокировпния её реальной записи?

По такой же логике, можно попробовать и по нулевому адресу писать, там гарантированный RO 😁. 

Хотя наверное я не прав, и у STM просто ремап на все LDR/STR, а там уж какое устройство отзеркалено (SRAM, FLASH), так и будет обрабатываться. 

Edited October 12, 2025 by Anxigeros

[jcxz 350]

8 часов назад, VladislavS сказал:

А  тупо запись во flash без разблокировпния её реальной записи?

Тупо вызывает Bus fault на STM32F4xx. Это при выключенном MPU. Но обычно MPU включен и естественно тогда для флеша выставлены атрибуты, вызывающие MPU fault при записи.

Не подходит.

4 часа назад, Anxigeros сказал:

По такой же логике, можно попробовать и по нулевому адресу писать, там гарантированный RO

Плохой вариант, так как туда может быть смаппирована или флешь или другая область памяти (в зависимости от BOOT-пинов). И поведение непредсказуемо.

 

Нужен регион в котором гарантированно ничего нет и не вызывающий fault-ов или иных неприятных осложнений при записи. Пока лучшие варианты: 0xE00F0000 или bitband-область.

 

PS: Кстати проверил bitband-область на скорость записи: Там дела ещё хуже, чем с областью 0xE000F000: запись в bitband на STM32F401 = 3 такта/слово. 

Такие результаты:

time =  77 tkt; tkts/u32 = 1.20 [0x2000BF00]
time = 137 tkt; tkts/u32 = 2.14 [0xE00F0000]
time = 197 tkt; tkts/u32 = 3.08 [0x22000000]

Первый столбец - время выполнения теста, 2-й - средняя удельная длительность одной 32-битной записи.

Для тестового кода выполняемого из ОЗУ [0x2000xxxx] (в R1 передаётся &DWT.CYCCNT):

               SECTION  .text:CODE:NOROOT(2)
               PUBLIC   tstz
               THUMB
tstz:          NOP
               alignrom 2, 0xBF00
               NOP
               CPSID    I
               LDR      R2, [R1]
               STMIA    R0!, {R0 - R7}
               STMIA    R0!, {R0 - R7}
               STMIA    R0!, {R0 - R7}
               STMIA    R0!, {R0 - R7}
               STMIA    R0!, {R0 - R7}
               STMIA    R0!, {R0 - R7}
               STMIA    R0!, {R0 - R7}
               STMIA    R0!, {R0 - R7}
               LDR      R0, [R1]
               LDR      R3, [R1]
               CPSIE    I
               SUBS     R3, R3, R0
               SUBS     R0, R0, R2
               SUBS     R0, R0, R3
               BX       LR

Расчёт удельных значений сделан без учёта длительности выполнения самих STMIA. Поэтому значения получились нецелые.

[dimka76 89]

On 10/11/2025 at 12:51 PM, jcxz said:

Имеется ли в микроконтроллерах на Cortex-M некий регион памяти, в котором реальной памяти нету, но запись любых данных в который не вызывает исключения? (сами данные не нужны)

Нужно это для оптимизации некоторого алгоритма.

Любопытства ради, а для чего такое вообще может понадобится ?
Писать в никуда.

[Anxigeros 2]

Неиспользуемая периферия? Та, у которой бит EN в RCC->{имя_шины}ENR выставлен в 0. Правда, периферии с большим кол-вом регистров не много (MAC, USB). 

Или же вообще пустые пространства под периферийные регистры (где в более старших чипах присутствует какой-нибудь UART7 или TIM13). 

Или как посоветовал @EdgeAligned, банки в 0xC0000000/0xD0000000 (правда, мне кажется, там 1 такта не будет, из-за "ретрансляции" инструкций чтения/записи). 

P. S. Мне казалось, что на STM32H7 доступ к "незаполненной" 0xE0000000 всегда приводил к BusFault. Правда, это было давно, на Cortex-M7, перепроверить не могу. 

[sasamy 10]

19 hours ago, sasamy said:

https://renode.io/about/

кстати для него есть графический фронтенд в vs code

https://marketplace.visualstudio.com/items?itemName=Ac6.splat

[jcxz 350]

2 часа назад, Anxigeros сказал:

Неиспользуемая периферия? Та, у которой бит EN в RCC->{имя_шины}ENR выставлен в 0. Правда, периферии с большим кол-вом регистров не много (MAC, USB). 

Нет таковой свободной.

2 часа назад, Anxigeros сказал:

Или же вообще пустые пространства под периферийные регистры (где в более старших чипах присутствует какой-нибудь UART7 или TIM13). 

Чем это лучше 0xE00F0000?

2 часа назад, Anxigeros сказал:

банки в 0xC0000000/0xD0000000

Ещё в начале темы писал уже не раз, что пробовал:

22 часа назад, jcxz сказал:

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

Пробовал всё это ещё до создания темы. Хоть немного почитайте, чтобы не идти по 2-му кругу.

3 часа назад, dimka76 сказал:

Любопытства ради, а для чего такое вообще может понадобится ?
Писать в никуда.

Я же писал в начале темы: "для оптимизации работы алгоритма".

Алгоритм может либо принимать данные в реальный буфер, либо должен выфлушить данные в dev->null. 2-й вариант - происходит редко. И чтобы не делать кучи условных ветвлений и не тормозить этим алгоритм, flush делаю в спец. буфер.

[dimka76 89]

On 10/13/2025 at 1:13 PM, jcxz said:

Алгоритм может либо принимать данные в реальный буфер, либо должен выфлушить данные в dev->null. 2-й вариант - происходит редко. И чтобы не делать кучи условных ветвлений и не тормозить этим алгоритм, flush делаю в спец. буфер.

1. почему нельзя данные в dev->null выфлушивать в тот же реальный буфер, просто просто потом ничего с этими данными не делать ?

2. данные в dev->null. Завести отдельный буфер единичного размера в реальном ОЗУ и выфлушивать в него, просто индекс не менять, а писать всегда в один и тот же индекс.