Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Использование EPCS64
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Системы на ПЛИС - System on a Programmable Chip (SoPC)
andrew89
Здравствуйте!
Помогите разобраться со следующей проблемой:
имеется отладочная плата Altera DE0-Nano c FPGA Cyclone IV EP4CE22 и конфигурационное ПЗУ EPCS64.
Требуется, чтобы по включению питания ПЛИС запускалась программа.
Преобразую (.sof) и (.elf) во (.flash) и загружаю в EPCS, всё согласно "User guide. Nios2 flash programmer".
После передергивания питания программа НЕ стартует сама. Если же запустить в консоли "nios2-terminal", программа запускается.
Запуск программы отслеживается по загоранию светодиода.

Вопрос: как сделать, чтобы программа стартовала сама, без запуска "nios2-terminal"?
Stewart Little
1. В системе должен присутствовать epсы_flash-controller.
2. Вектор сброса процессора должен указывать на него.
3. В bsp надо запретить исполнение кода приложения с адреса сброса.

Покажите Ваши настройки bsp.
serjj
Блокирующий printf мб где то ее подвешивает? Там вроде 2 варианта реализации printf в зависимости от настроек BSP, в одном случае требуется подключенная JTAG консоль - в другом нет. Вообще лучше из автономной программы printf убирать
andrew89
Цитата(Stewart Little @ Jan 15 2015, 12:28) *
1. В системе должен присутствовать epсы_flash-controller.
2. Вектор сброса процессора должен указывать на него.
3. В bsp надо запретить исполнение кода приложения с адреса сброса.

Покажите Ваши настройки bsp.


1 и 2 пункты сделаны были.
а 3й пункт - галка убрана "allow code at reset" - вы это имели ввиду?

Цитата(serjj @ Jan 15 2015, 12:30) *
Блокирующий printf мб где то ее подвешивает? Там вроде 2 варианта реализации printf в зависимости от настроек BSP, в одном случае требуется подключенная JTAG консоль - в другом нет. Вообще лучше из автономной программы printf убирать

printf не использую
WitFed
Могу предложить "по-живому" подключиться к свежевключенной программе отладчиком и глянуть, где она ждёт чего-то вечно. Вдруг всё не в раскоряке. Дебужная информация же есть, имена функций будут видны в дизассемблере, стек...
Если совсем мусор наблюдается -- можно в main() поставить "while (1) ;" и подключиться, затем перейти к следующим строкам и дебажить по-человечески до проблемы.
Ну а если вообще не коннектится -- это загрузчик недоработал, программа не стартовала в принципе, отлаживать/просматривать надо загрузчик.
Выгружать содержимое всей памяти можно в хорошем (старт под отладчиком) и плохом случаях для сравнения -- код отличаться не должен, ну в данных что-то может тронуться...
Вообще, если пуск nios2-terminal-а "оживляет" старт уже включённого устройства, то там точно ожидается наличие хоста, которое в реале надо отрубить.
У меня похожее было в ARM-e на Cyclone V -- не доходя до main(), буквально на 7й asm-команде вызывается запрос системной библиотеки на семихостинг SVC -- открытие stdin или stdout, а отладчика нет, обработчика этого прерывания тоже -- и всё зацикливается навечно в дефолтном обработчике.
andrew89
Цитата(WitFed @ Jan 16 2015, 16:34) *
У меня похожее было в ARM-e на Cyclone V -- не доходя до main(), буквально на 7й asm-команде вызывается запрос системной библиотеки на семихостинг SVC -- открытие stdin или stdout, а отладчика нет, обработчика этого прерывания тоже -- и всё зацикливается навечно в дефолтном обработчике.

И каким способом вам удалось решить эту проблему?

P.S. Можно ли предположить, что Nios2 добавляет к рабочему коду нашей программы код отладчика, который запускает нашу программу по команде "nios2-terminal"? И задача состоит в отключении кода отладчика?
wpost
На циклоне 5 при использовании DDR2 озу для ниоса программа грузится из epcs в озу, но не стартует. проблема решается рукописным копировщиком на базе onchipmemory. Возможно тут что-то похожее.

попробуйте сделать аппаратный сброс системы (ниоса) по включению питания.
Попробуйте на ончип озу запуститься.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.