Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: периодически не получается в SDK сделать RUN AS для Release конфигурации, выдаёт ошибку
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Системы на ПЛИС - System on a Programmable Chip (SoPC)
Krys
Здравствуйте. Периодически не получается в SDK сделать RUN AS для Release конфигурации, выдаёт ошибку и не запускается. При том это начинается на пустом месте, ни с того ни с сего. Уже 2й раз заловил. Потом мучился-мучился, как-то заработало. Работало-работало, потом перестала. Чото делал-делал, один раз заработало, потом опять не работало...
При этом DEBUG AS работает нормально.
Программа у меня целиком в DDR, и данные, и код. Вот линкер скрипт:

CODE


/*******************************************************************/
/* */
/* This file is automatically generated by linker script generator.*/
/* */
/* Version: Xilinx EDK 14.7 EDK_P.20131013 */
/* */
/* Copyright © 2010 Xilinx, Inc. All rights reserved. */
/* */
/* Description : MicroBlaze Linker Script */
/* */
/*******************************************************************/

_STACK_SIZE = DEFINED(_STACK_SIZE) ? _STACK_SIZE : 0x989680;
_HEAP_SIZE = DEFINED(_HEAP_SIZE) ? _HEAP_SIZE : 0x5F5E100;

/* Define Memories in the system */

MEMORY
{
microblaze_0_i_bram_ctrl_microblaze_0_d_bram_ctrl : ORIGIN = 0x00000050, LENGTH = 0x00001FB0
mcb_ddr3_S0_AXI_BASEADDR : ORIGIN = 0xA8000000, LENGTH = 0x08000000
}

/* Specify the default entry point to the program */

ENTRY(_start)

/* Define the sections, and where they are mapped in memory */

SECTIONS
{
.vectors.reset 0x00000000 : {
KEEP (*(.vectors.reset))
}

.vectors.sw_exception 0x00000008 : {
KEEP (*(.vectors.sw_exception))
}

.vectors.interrupt 0x00000010 : {
KEEP (*(.vectors.interrupt))
}

.vectors.hw_exception 0x00000020 : {
KEEP (*(.vectors.hw_exception))
}

.text : {
*(.text)
*(.text.*)
*(.gnu.linkonce.t.*)
} > mcb_ddr3_S0_AXI_BASEADDR

.init : {
KEEP (*(.init))
} > mcb_ddr3_S0_AXI_BASEADDR

.fini : {
KEEP (*(.fini))
} > mcb_ddr3_S0_AXI_BASEADDR

.ctors : {
__CTOR_LIST__ = .;
___CTORS_LIST___ = .;
KEEP (*crtbegin.o(.ctors))
KEEP (*(EXCLUDE_FILE(*crtend.o) .ctors))
KEEP (*(SORT(.ctors.*)))
KEEP (*(.ctors))
__CTOR_END__ = .;
___CTORS_END___ = .;
} > mcb_ddr3_S0_AXI_BASEADDR

.dtors : {
__DTOR_LIST__ = .;
___DTORS_LIST___ = .;
KEEP (*crtbegin.o(.dtors))
KEEP (*(EXCLUDE_FILE(*crtend.o) .dtors))
KEEP (*(SORT(.dtors.*)))
KEEP (*(.dtors))
PROVIDE(__DTOR_END__ = .);
PROVIDE(___DTORS_END___ = .);
} > mcb_ddr3_S0_AXI_BASEADDR

.rodata : {
__rodata_start = .;
*(.rodata)
*(.rodata.*)
*(.gnu.linkonce.r.*)
__rodata_end = .;
} > mcb_ddr3_S0_AXI_BASEADDR

.sdata2 : {
. = ALIGN(8);
__sdata2_start = .;
*(.sdata2)
*(.sdata2.*)
*(.gnu.linkonce.s2.*)
. = ALIGN(8);
__sdata2_end = .;
} > mcb_ddr3_S0_AXI_BASEADDR

.sbss2 : {
__sbss2_start = .;
*(.sbss2)
*(.sbss2.*)
*(.gnu.linkonce.sb2.*)
__sbss2_end = .;
} > mcb_ddr3_S0_AXI_BASEADDR

.data : {
. = ALIGN(4);
__data_start = .;
*(.data)
*(.data.*)
*(.gnu.linkonce.d.*)
__data_end = .;
} > mcb_ddr3_S0_AXI_BASEADDR

.got : {
*(.got)
} > mcb_ddr3_S0_AXI_BASEADDR

.got1 : {
*(.got1)
} > mcb_ddr3_S0_AXI_BASEADDR

.got2 : {
*(.got2)
} > mcb_ddr3_S0_AXI_BASEADDR

.eh_frame : {
*(.eh_frame)
} > mcb_ddr3_S0_AXI_BASEADDR

.jcr : {
*(.jcr)
} > mcb_ddr3_S0_AXI_BASEADDR

.gcc_except_table : {
*(.gcc_except_table)
} > mcb_ddr3_S0_AXI_BASEADDR

.sdata : {
. = ALIGN(8);
__sdata_start = .;
*(.sdata)
*(.sdata.*)
*(.gnu.linkonce.s.*)
__sdata_end = .;
} > mcb_ddr3_S0_AXI_BASEADDR

.sbss (NOLOAD) : {
. = ALIGN(4);
__sbss_start = .;
*(.sbss)
*(.sbss.*)
*(.gnu.linkonce.sb.*)
. = ALIGN(8);
__sbss_end = .;
} > mcb_ddr3_S0_AXI_BASEADDR

.tdata : {
__tdata_start = .;
*(.tdata)
*(.tdata.*)
*(.gnu.linkonce.td.*)
__tdata_end = .;
} > mcb_ddr3_S0_AXI_BASEADDR

.tbss : {
__tbss_start = .;
*(.tbss)
*(.tbss.*)
*(.gnu.linkonce.tb.*)
__tbss_end = .;
} > mcb_ddr3_S0_AXI_BASEADDR

.bss (NOLOAD) : {
. = ALIGN(4);
__bss_start = .;
*(.bss)
*(.bss.*)
*(.gnu.linkonce.b.*)
*(COMMON)
. = ALIGN(4);
__bss_end = .;
} > mcb_ddr3_S0_AXI_BASEADDR

_SDA_BASE_ = __sdata_start + ((__sbss_end - __sdata_start) / 2 );

_SDA2_BASE_ = __sdata2_start + ((__sbss2_end - __sdata2_start) / 2 );

/* Generate Stack and Heap definitions */

.heap (NOLOAD) : {
. = ALIGN(8);
_heap = .;
_heap_start = .;
. += _HEAP_SIZE;
_heap_end = .;
} > mcb_ddr3_S0_AXI_BASEADDR

.stack (NOLOAD) : {
_stack_end = .;
. += _STACK_SIZE;
. = ALIGN(8);
_stack = .;
__stack = _stack;
} > mcb_ddr3_S0_AXI_BASEADDR

_end = .;
}




Вот тут кое-какой ответ есть: http://www.xilinx.com/support/answers/45834.html
Но мне такой ответ не подходит, т.к. у меня это не всегда не работает, а периодами. И я не хочу, как там советуют, использовать Debug As, мне надо Run As, т.к. конфигурация не Debug, а Release, и инструмент запуска должен быть соответствующий. Я не уверен, но предполагаю, что неправильно конфигурацию Release запускать через Debug As, т.к. может что-то не так работать или быстродействие будет ниже (мне крайне важно быстродействие при обмене по DDR, заметил, что оно хуже для конфигурации Debug и запуска через Debug As примерно в 2 раза). Если я неправ, то поправьте, пожалуйста.

Я новичок во встраиваемых системах, поэтому вполне допускаю, что я просто "не умею их готовить".

Заодно вопрос почти по теме (возможно ещё и в этом загвоздка): когда я загружаю прошивку, я могу указать бинарник либо system.bit, либо download.bit. И *.bmm файл могу указывать, а могу и нет. Я так понял, что в *.bmm лежит дамп того, что требуется залить в блочную память. Если у меня все сегменты расположены в DDR, то и *.bmm мне вообще не нужен?
Как вообще здесь правильно надо какие файлы подставлять?
Krys
Пока пересоздал проект, вроде помогло...
Krys
Пока что-то делал, опять перестала запускаться, сейчас такая фигня вылазит:

Нажмите для просмотра прикрепленного файла

Надоела уже... опять что ли проект пересоздавать... по нескольку раз на дню... должно же быть какое-то решение? Не у меня же одного...
aabmail
Цитата(Krys @ Dec 16 2014, 08:42) *
Здравствуйте. Периодически не получается в SDK сделать RUN AS для Release конфигурации, выдаёт ошибку и не запускается. При том это начинается на пустом месте, ни с того ни с сего. Уже 2й раз заловил. Потом мучился-мучился, как-то заработало. Работало-работало, потом перестала. Чото делал-делал, один раз заработало, потом опять не работало...
При этом DEBUG AS работает нормально.
Программа у меня целиком в DDR, и данные, и код. Вот линкер скрипт:


Какая у Вас версия EDK/SDK?


Цитата(Krys @ Dec 16 2014, 08:42) *
Заодно вопрос почти по теме (возможно ещё и в этом загвоздка): когда я загружаю прошивку, я могу указать бинарник либо system.bit, либо download.bit. И *.bmm файл могу указывать, а могу и нет. Я так понял, что в *.bmm лежит дамп того, что требуется залить в блочную память. Если у меня все сегменты расположены в DDR, то и *.bmm мне вообще не нужен?
Как вообще здесь правильно надо какие файлы подставлять?

Если Вы исполняете программу из DDR, и при этом загружаете туда программу через отладчик c помощью SDK, то BMM-файл не нужен. Также в этом случае не имеет значения, какую Вы будете использовать конфигурацию - system.bit или download.bit.

Цитата
Я так понял, что в *.bmm лежит дамп того, что требуется залить в блочную память.


Нет, это не дамп. Это адреса BRAМ-блоков, которые выделены для microBlaze. Файл system_bd.bmm нужен утилите data2mem, чтобы сгенерировать download.bit. Т.е. download.bit <= system.bit + .elf + system_bd.bmm


Цитата
Чото делал-делал, один раз заработало, потом опять не работало...

Когда у меня стояла 14.2, то все время вот так вот глючило, особенно если выключить плату при включенном отладчике. Приходилось все перезагружать, а также заходить в диспетчер задач и выкидывать javaw.exe из памяти. В 14.7 этих глюков поубавилось.
Krys
aabmail, спасибо за разъяснения. У меня ISE 14.7 и все инструменты из этой версии.

Цитата(aabmail @ Dec 16 2014, 23:48) *
Если Вы исполняете программу из DDR, и при этом загружаете туда программу через отладчик c помощью SDK, то BMM-файл не нужен. Также в этом случае не имеет значения, какую Вы будете использовать конфигурацию - system.bit или download.bit.
Для такого условия понятно. Вы могли бы ещё разъяснить, при каких условиях используется download.bit? Только когда программа не загружается через отладчик, а содержится в самой прошивке?

Цитата(aabmail @ Dec 16 2014, 23:48) *
Нет, это не дамп. Это адреса BRAМ-блоков, которые выделены для microBlaze. Файл system_bd.bmm нужен утилите data2mem, чтобы сгенерировать download.bit. Т.е. download.bit <= system.bit + .elf + system_bd.bmm

Прошёлся поиском по проекту, у меня файлов *.bmm аж 4:
Код
planahead\fft_sp605\fft_sp605.runs\impl_1\module_1_stub.bmm
planahead\fft_sp605\fft_sp605.runs\impl_1\module_1_stub_bd.bmm
planahead\fft_sp605\fft_sp605.srcs\sources_1\edk\module_1\implementation\module_1.bmm
planahead\fft_sp605\fft_sp605.srcs\sources_1\edk\module_1\implementation\module_1_stub.bmm


Начал путаться, какие файлы являются исходниками, а какие результатами? При том есть просто module_1_stub, а есть module_1_stub_bd. Вы не знаете, что из каких образуется? При том в папке .srcs лежат такие же файлы, как и в .runs, но меньшего размера. Я посмотрел по размеру, получается, что в SDK_EXPORT попадает файл из .runs. Какая тут логика и взаимосвязь, не в курсе? (Вопрос отчасти связан с тем, что я пытаюсь найти набор файлов, достаточных для хранения в репозитории, из которых потом можно развернуть весь проект).

Цитата(aabmail @ Dec 16 2014, 23:48) *
Когда у меня стояла 14.2, то все время вот так вот глючило, особенно если выключить плату при включенном отладчике. Приходилось все перезагружать, а также заходить в диспетчер задач и выкидывать javaw.exe из памяти. В 14.7 этих глюков поубавилось.
Не помогло...
Krys
На этот раз помогло перезагрузить компьютер, запустить сначала Debug конфигурацию через Debug As - System debugger (TCF). Затем отсоединиться (Disconnect), переключиться на Release и выполнить Run As... (GDB).
Пока работается - поработаю на этом. Как ещё раз вылезет - посмотрим что ещё делать...
Krys
Нашёл ещё парочку подсказок:
http://forums.xilinx.com/xlnx/board/crawl_...essage.id=29935
http://www.xilinx.com/support/answers/39667.html
http://www.xilinx.com/support/answers/56628.html
Мне правда они не помогли, но может кому-то будет польза...
aabmail
Если программа в Вашем случае будет исполняться из DDR, тогда она и не может находиться в прошивке. Если же идет речь об исполнении программы из BRAM, то тогда используются download.bit и system_bd.bmm. В последнем указано, в каких конкретно BRAM будет размещена программа. _bd от не _bd отличается тем, что в _bd указаны места расположения bram в ПЛИС. Все .bmm не являются исходниками, а генерируются программами ngdbuild и par на основе mhs.
Krys
Большое спасибо, так гораздо понятнее. Но есть ещё туманности:
Цитата(aabmail @ Dec 17 2014, 16:32) *
В последнем указано, в каких конкретно BRAM будет размещена программа. _bd от не _bd отличается тем, что в _bd указаны места расположения bram в ПЛИС.
Как я понял из Ваших предыдущих сообщений, во всех *.bmm находятся рам-блоки. Правильно ли я понимаю, что в не _bd находятся все рам-блоки, а в _bd дополнительно описаны ещё и те, которые предназначены для микроблэйза?


А по поводу этого моего вопроса, не разъясните?
Цитата
При том в папке .srcs лежат такие же файлы, как и в .runs, но меньшего размера. Я посмотрел по размеру, получается, что в SDK_EXPORT попадает файл из .runs.
Если опираться на то, что Вы сказали:
Цитата(aabmail @ Dec 17 2014, 16:32) *
Все .bmm не являются исходниками, а генерируются программами ngdbuild и par на основе mhs.
, то получается, что после генерации из *.mhs "правильные" *.bmm лежат в папке
Код
planahead\fft_sp605\fft_sp605.srcs\sources_1\edk\module_1\implementation\
. Но в SDK_EXPORT то получается файлы берутся из .runs. Я могу предположить следующую логику:
1. из *.mhs под названием module_1 в .srcs получается *.bmm под названием module_1.
2. Но весь проект - это не только module_1, т.к. он входит в топовый файл module_1_stub.v
3. Поэтому для всего проекта на основе module_1.bmm получается общая *.bmm под названием module_1_stub.bmm.
4. Какая логика происходит, когда module_1_stub.bmm из .srcs попадает в .runs - я не знаю, но размер увеличивается примерно в 2 раза. Собственно прошу это и пояснить.
5. Если в module_1_stub.bmm в .runs хранятся все рам-блоки, то на его основе подготавливается module_1_stub_bd.bmm, где указаны те, что нужны для микроблэйза. Размер ещё увеличивается.

Что тут правильно, что не так?
aabmail
Цитата(Krys @ Dec 18 2014, 06:38) *
Как я понял из Ваших предыдущих сообщений, во всех *.bmm находятся рам-блоки. Правильно ли я понимаю, что в не _bd находятся все рам-блоки, а в _bd дополнительно описаны ещё и те, которые предназначены для микроблэйза?

Оба .bmm описывают одни и те же Block-RAM-блоки, находящиеся в адресном пространстве микропроцессора (или -ов). System_bd.bmm содержит более подробную информацию о них - их двумерные адреса в ПЛИСе. Более подробно о BMM можно почитать в UG437.
Krys
Ага, спасибо, надо было мне лучше сразу спросить, где про это прочитать. Читать то я непротив, особенно когда в каком-то источнике можно найти краткий, чётко локализованный ответ.
Krys
Я похоже разобрался в своей проблеме с запуском из первого поста. Это у меня лыжи не ехали, я же новичок во встраиваемых системах ))) Правда за последнее время я уже похоже на многие грабли наступил, шишек набил, можно уже из новичков меня вычёркивать)

Короче дело было в том, что я не умел правильно управляться с конфигурациями запусков.
Предлагаю для новичков, кто ещё будет наступать на эти грабли, следующую инструкцию.
Для начала надо зайти в Run - Debug Configurations (если у вас конфигурация дебаг. Если релиз - то соответственно в Run Configurations). И удалить оттуда всё лишнее, чтобы не путаться:

Нажмите для просмотра прикрепленного файла

Затем нужно создать конфигурацию. В дереве проекта выбрать в своей конфигурации свой исполняемый файл, и нажать правой кнопкой, выбрав как на картинке (средство отладки может быть другим - какое вам нужно):

Нажмите для просмотра прикрепленного файла

В принципе всё запустится, как надо. Но если не запустилось, можно ещё раз дополнительно зайти в Run - Debug Configurations и убедиться, что в вашей конфигурации присутствуют правильные параметры (помечено красным) и главное правильные пути до нужной конфигурации и до нужного файла. Можно ещё через кнопку Browse убедиться, что это то, что надо. Можно даже для уверенности переименовать эту конфигурацию в уникальное для вас имя, чтобы быть уверенным, что это именно ваша конфигурация.

Нажмите для просмотра прикрепленного файла

Так мы создали конфигурацию запуска. В следующий раз её уже по указанной выше инструкции создавать не надо. И не надо удалять предыдущие конфигурации. Пусть у вас эта конфигурация так и будет.

Чтобы запустить выполнение в следующий раз (допустим после закрытия - открытия SDK) нужно зайти в Run - Debug Configurations, выбрать ту конфигурацию, которую вы создали, и внизу нажать Debug. Всё опять запустится.

Если SDK не закрывался, то при нажатии на жучка:
Нажмите для просмотра прикрепленного файла
...запустится последняя успешно запущенная ранее конфигурация. Если SDK только что запущен, то последней конфигурации не существует. Какая последняя конфигурация запомнилась системой можно посмотреть, нажав на стрелочку рядом с жучком. Если пусто (после старта SDK) - значит ничего при нажатии на жучка и не запустится. Тогда надо запускать через Run - Debug Configurations. По этой же стрелочке можно быстро выбрать одну из последних запущенных конфигураций для текущего запуска (бывает, что конфигурации разные для разных целей). Т.е. стрелочка - это и история конфигураций, и средство выбора текущей для запуска.

Если вы работаете не с конфигурацией Debug, а с Release - то всё вышеперечисленное справедливо, только в соответствующих местах слово Debug заменяется на Run.

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