Статьи

Целевой объем ОЗУ с Kinetis Design Studio и FRDM-K64F

Более новые микроконтроллеры имеют увеличенные области оперативной памяти, что делает его пригодным для запуска приложения из оперативной памяти вместо флэш-памяти. Для платы FRDM-K64F и Kinetis Design Studio (V1.1.1) я изучил, как запускать приложение из ОЗУ вместо флэш-памяти, как для соединений P & E, так и для Segger.

MK64FN1M0VLL12

MK64FN1M0VLL12

Почему конфигурация RAM

Мой инженерный принцип таков: инженер должен развиваться в среде, которая позже будет использована в производстве (см. « Отладка или выпуск?«). Просто потому, что если вы разрабатываете и отлаживаете, каким будет продукт, у вас больше шансов обнаружить ошибки на ранней стадии. То же самое относится к объектам RAM или FLASH. С целевыми значениями ОЗУ код и приложение выполняются в ОЗУ, в то время как с помощью FLASH не хватает памяти FLASH. В первые дни технологии микроконтроллера FLASH циклы стирания программы FLASH были ограничены: мой первый микроконтроллер позволял перепрограммировать FLASH только 50 раз! Поэтому имеет смысл начать сначала разрабатывать в ОЗУ, а не изнашивать флэш-память слишком рано. Еще одним преимуществом (в прошлом) было то, что загрузка в ОЗУ была быстрее, чем во FLASH. Но с более быстрыми проблесками FLASH и отладки это больше не нужно. Помимо этого: запуск программы из оперативной памяти может быть быстрее, чтобы повысить производительность приложения.

K64F на плате FRDM-K64F имеет 256 КБ ОЗУ, поэтому можно запускать довольно большие программы из ОЗУ.

Память на устройствах Freescale Kinetis-K * не * непрерывна! В 0x2000’0000 есть барьер памяти, который сегментирует память, поэтому вы не можете использовать эту память одним куском! См. « Куча FreeRTOS с сегментированной памятью Kinetis K ».

Загрузка и отладка целевого ОЗУ довольно проста с Kinetis Design Studio и проектами, созданными с помощью Processor Expert.

256 Кбайт ОЗУ K64F

256 Кбайт ОЗУ K64F

Использование конфигурации RAM

Мастер создает проект с конфигурацией RAM и FLASH, с FLASH, установленной по умолчанию (см. « Конфигурации с помощью Processor Expert »):

Процессорный экспертный проект для FRDM-K64F

Процессорный экспертный проект для FRDM-K64F

Чтобы переключить конфигурацию, я выбираю ее и использую контекстное меню:

Выбор конфигурации

Выбор конфигурации

Это делает активную конфигурацию RAM. Обратите внимание, что теперь в этой конфигурации выбран другой ЦП:

Выбранная конфигурация RAM

Выбранная конфигурация RAM

Отличие от цели FLASH заключается в том, что в параметрах сборки ЦПУ весь код и данные помещаются в области ОЗУ:

Код и данные, размещенные в оперативной памяти

Код и данные, размещенные в оперативной памяти

Поэтому сгенерированный файл компоновщика также использует области ОЗУ и помещает код и данные в ОЗУ, за исключением области конфигурации и защиты FLASH (CFMPROT):

MEMORY {
  m_interrupts (RX) : ORIGIN = 0x20000000, LENGTH = 0x00000198
  m_text  (RX) : ORIGIN = 0x20000198, LENGTH = 0x0002FE68
  m_data  (RW) : ORIGIN = 0x1FFF0000, LENGTH = 0x00010000
  m_cfmprotrom  (RX) : ORIGIN = 0x00000400, LENGTH = 0x00000010
}

Отладка в ОЗУ

Р & Е

Debugging a RAM configuration with the P&E connection is the same as using the FLASH configuration, no other changes needed:

Отладка в оперативной памяти с помощью P & E

Debugging in RAM with P&E

Segger

If using the Segger J-Link connection, then have to disable the ‘Pre-run reset and halt’ in the debug/launch configuration:

Настройка запуска отладчика Segger для отладки в оперативной памяти

Segger Debugger Launch Configuration to Debug in RAM

With this, I can download and debug in RAM:

Отладка в ОЗУ с помощью Segger

Debugging in RAM with Segger

OpenOCD/CMSIS-DAP

Same for the OpenOCD connection: I need to disable ‘Pre-run reset’ in the debugger lauch configuration:

Конфигурация отладки для отладки в оперативной памяти с OpenOCD

Debug Configuration for Debugging in RAM with OpenOCD

With this, debugging in RAM works:

Отладка в ОЗУ с помощью OpenOCD

Debugging in RAM with OpenOCD

Summary

If you have enough RAM, it *might* make sense to run your application and to debug it in RAM. This means that in the linker file the code and data needs to be placed into RAM. I’m of the opinion that you should debug what you intend to build, but if you insist on debugging in RAM, hopefully this article helps you. And do not forget: if you power off the target, your application in RAM is gone ?

Happy RAMing ?