caxapa.ru :: Во первых, вы должны знать, что тактирование любой периферии включается через регистры группы RCC с суффиксом ENR (Enable Register). Следующая запись эквивалентна вашей:

evgeniy1294 (22.02.2021 13:54, просмотров: 483) ответил Kceния на Попробовала на своей плате - заработало, но не сразу. Сперва компилироваться не хотело, когда в SRAM1-2-3 что-то пишется или оттуда читается, причем сообщение компилятора невразумительное - типа "не могу инициализировать нулями секцию .bss". Исследование показало, что причина в ином - массивы, размещенные мной в SRAM1-2-3, имели нечетное число элементов uint16_t. Только после того, как удалось об этом догадаться, память заработала. В среде CubeMX оказалось необязательным

Во первых, вы должны знать, что тактирование любой периферии включается через регистры группы RCC с суффиксом ENR (Enable Register). Следующая запись эквивалентна вашей:

RCC->AHB2ENR = RCC->AHB2ENR | RCC_AHB2ENR_SRAM1EN | RCC_AHB2ENR_SRAM2EN | RCC_AHB2ENR_SRAM3EN;

Дока на чип говорит, что значение регистра RCC->AHB2ENR после ресета 0, а значит и тактирование памяти отключено. Соответственно, если вы пихаете секцию bss в в эти области памяти, то их необходимо затактировать сразу после входа в ResetHandler. Иначе словите BusFault

"не могу инициализировать нулями секцию .bss" - звучит бредово, компилятор ничего нигде не инициализирует, может только запихнуть переменные в нужный диапазон адресов, обычно bss или data, к тому же F7 умеет невыровненный доступ к памяти. Четное/нечетное число элементов значения не имеет, линкер все равно сделает выравнивание по 4 байта. Скорее всего запорот скрипт линкера, он не может впихнуть все в секцию

Ответить

- Компилятор помещает массивы в секцию (вероятно bss), где вся эта секция обнуляется startup-кодом еще до входа в main(). Все так делают, нулями прошивку не заполняют. В ARMе заполнение нулями происходит 32-битными порциями (обнуленный регистр в цикле копируется в память), видимо из-за этого ее размер в байтах должен делиться на 4 байта без остатка. Позже я нашла иной способ - через дефиницию __no_init, тогда линкер размещает массив в другой сегмент, который при старте Kceния(699 знак., 22.02.2021 14:26)
  - Не самое лучшее решение размещать в памяти данные через директивы компилятора, я бы даже сказал максимально плохое. Нужно размещать секции через скрипт линкера, которому дополнительно можно объяснить, какие объекты куда класть. Код из куба делает следующее: evgeniy1294(873 знак., 22.02.2021 14:58)
    - Всё равно бы пришлось писать #pragma location, только не на точный адрес, а на имя сегмента. Я бы так и сделала, если бы у меня в SRAM123 было бы еще что-то, но раз уж в каждой из этих SRAMx у меня всего по одному массиву, то решила с определением дополнительных секций не заморачиваться, тем паче что писать задания для линкера я не шибко умею :). А код с дефайнами из CubeMX мне объяснять не надо - он мне и самой понятен, неясно только чем RCC_AHB2ENR_D2SRAM1EN Kceния(191 знак., 22.02.2021 20:23)
      - D2 - домен питания. Код скорее всего универсален для всего семейства H7, а может быть даже и для F7, не во всех из которых этот домен есть. Что касается DATA_IN_D2_SRAM, видимо где-то определение таки есть, возможно в настройках проекта. - evgeniy1294(22.02.2021 20:27)
        
        Вопрос чуть в сторону: когда D-Cache включают, то оно на SRAM1-2-3 действует? Это которое: Kceния(51 знак., 22.02.2021 22:08)
        
        Блок-схема в даташите говорит, что да, без разницы. - evgeniy1294(22.02.2021 23:13)
        
        Это грустно... Хотя говорят, что через MCU поправимо. А стоит ли мне вернуться с AXI на DTCM теперь (после того, как DMA-процессы вынесла в SRAM123)? Есть ли разница, где ОЗУ у программы располагать? - Kceния(23.02.2021 15:09)
        
        Немного поправлю: через MPU, AXI - это шина, TCM - память. В TCM обычно помещают стэк и данные программы, с которыми не требуется работать через DMA. - evgeniy1294(23.02.2021 15:53)
        
        Речь шла об MPU (Memory Protection Unit), с помощью которой якобы можно задавать, какие области памяти не надо кэшировать => - Kceния(23.02.2021 16:20, ссылка)
        
        есть. но небольшая - Mahagam(23.02.2021 15:29)
        
        А вот здесь мужик жалуется, что у него AXI работает вдвое медленнее, чем DTCM, т.е. почти со скоростью flash => - Kceния(23.02.2021 17:17, ссылка)
        
        Частота шины AXI 240МГц. Не помню точно спецификацию шины, но процесс чтения может занять пару тактов шины. - evgeniy1294(23.02.2021 17:31)
        
        От этого вашего замечания нет проку, поскольку эти 240 МГц не с чем сравнивать - про частоту DTCM вы умалчиваете. Вдруг DTCM работает с частотой ядра (480 МГц), и тогда тот мужик прав. - Kceния(23.02.2021 18:06)
        
        Там на шине ещё и арбитраж. Есть вот такая интересная презентация: - evgeniy1294(23.02.2021 18:55, ссылка)
        
        Только арбитража мне еще не хватало :) - Kceния(23.02.2021 19:35)
        
        Ксения, хотите предсказуемых задержек - берите PRU и работайте только с регистрами. Во всех остальных случаях латентность уже lloyd(407 знак., 23.02.2021 20:51)
        
        Я лишь только спросила, имеет ли смысл ради ускорения работы кода вернуть ОЗУ программы из AXI назад в DTCM. Причем, миграция на AXI была связана с тем, что на DTCM не работает DMA. После того, как буферы DMA удалось расположить в области SRAM1-2-3, необходимость жития на AXI исчезла, и возник вопрос о выборе между AXI и DTCM. Ответы же на этот вопрос крайне противоречивы - различаются в два раза. - Kceния(23.02.2021 23:11)
        
        The L1-cache can be a performance booster when used in conjunction with memory interfaces on AXI bus. This must not be confused with memories on the Tightly Couple Memory (TCM) interface, which are not cacheable. Any normal memory area can be cacheable, as described above, but the biggest gains are seen on memories accessed by the AXI bus such as the internal Flash memory, internal SRAMs and external memories attached to the FMC or Quad-SPI controllers - evgeniy1294(23.02.2021 00:15)

ARM, RISC-V контроллеры