Более новые микроконтроллеры имеют увеличенные области оперативной памяти, что делает его пригодным для запуска приложения из оперативной памяти вместо флэш-памяти. Для платы FRDM-K64F и Kinetis Design Studio (V1.1.1) я изучил, как запускать приложение из ОЗУ вместо флэш-памяти, как для соединений P & E, так и для Segger.
Почему конфигурация 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.
Использование конфигурации RAM
Мастер создает проект с конфигурацией RAM и FLASH, с FLASH, установленной по умолчанию (см. « Конфигурации с помощью Processor Expert »):
Чтобы переключить конфигурацию, я выбираю ее и использую контекстное меню:
Это делает активную конфигурацию 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:
Segger
If using the Segger J-Link connection, then have to disable the ‘Pre-run reset and halt’ in the debug/launch configuration:
With this, I can download and debug in RAM:
OpenOCD/CMSIS-DAP
Same for the OpenOCD connection: I need to disable ‘Pre-run reset’ in the debugger lauch configuration:
With this, debugging in RAM works:
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 ?