[Krys 2]

Здравствуйте. Периодически не получается в SDK сделать RUN AS для Release конфигурации, выдаёт ошибку и не запускается. При том это начинается на пустом месте, ни с того ни с сего. Уже 2й раз заловил. Потом мучился-мучился, как-то заработало. Работало-работало, потом перестала. Чото делал-делал, один раз заработало, потом опять не работало...

При этом DEBUG AS работает нормально.

Программа у меня целиком в DDR, и данные, и код. Вот линкер скрипт:

 

/*******************************************************************/
/*                                                                 */
/* 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 2]

Пока пересоздал проект, вроде помогло...

[Krys 2]

Пока что-то делал, опять перестала запускаться, сейчас такая фигня вылазит:

 

 

Надоела уже... опять что ли проект пересоздавать... по нескольку раз на дню... должно же быть какое-то решение? Не у меня же одного...

[aabmail 0]

Здравствуйте. Периодически не получается в SDK сделать RUN AS для Release конфигурации, выдаёт ошибку и не запускается. При том это начинается на пустом месте, ни с того ни с сего. Уже 2й раз заловил. Потом мучился-мучился, как-то заработало. Работало-работало, потом перестала. Чото делал-делал, один раз заработало, потом опять не работало...

При этом DEBUG AS работает нормально.

Программа у меня целиком в DDR, и данные, и код. Вот линкер скрипт:

 

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

 

 

Заодно вопрос почти по теме (возможно ещё и в этом загвоздка): когда я загружаю прошивку, я могу указать бинарник либо 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 2]

aabmail, спасибо за разъяснения. У меня ISE 14.7 и все инструменты из этой версии.

 

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

Для такого условия понятно. Вы могли бы ещё разъяснить, при каких условиях используется download.bit? Только когда программа не загружается через отладчик, а содержится в самой прошивке?

 

Нет, это не дамп. Это адреса 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. Какая тут логика и взаимосвязь, не в курсе? (Вопрос отчасти связан с тем, что я пытаюсь найти набор файлов, достаточных для хранения в репозитории, из которых потом можно развернуть весь проект).

 

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

Не помогло...

 

[Krys 2]

На этот раз помогло перезагрузить компьютер, запустить сначала Debug конфигурацию через Debug As - System debugger (TCF). Затем отсоединиться (Disconnect), переключиться на Release и выполнить Run As... (GDB).

Пока работается - поработаю на этом. Как ещё раз вылезет - посмотрим что ещё делать...

[Krys 2]

Нашёл ещё парочку подсказок:

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 0]

Если программа в Вашем случае будет исполняться из DDR, тогда она и не может находиться в прошивке. Если же идет речь об исполнении программы из BRAM, то тогда используются download.bit и system_bd.bmm. В последнем указано, в каких конкретно BRAM будет размещена программа. _bd от не _bd отличается тем, что в _bd указаны места расположения bram в ПЛИС. Все .bmm не являются исходниками, а генерируются программами ngdbuild и par на основе mhs.

[Krys 2]

Большое спасибо, так гораздо понятнее. Но есть ещё туманности:

В последнем указано, в каких конкретно BRAM будет размещена программа. _bd от не _bd отличается тем, что в _bd указаны места расположения bram в ПЛИС.

Как я понял из Ваших предыдущих сообщений, во всех *.bmm находятся рам-блоки. Правильно ли я понимаю, что в не _bd находятся все рам-блоки, а в _bd дополнительно описаны ещё и те, которые предназначены для микроблэйза?

 

 

А по поводу этого моего вопроса, не разъясните?

При том в папке .srcs лежат такие же файлы, как и в .runs, но меньшего размера. Я посмотрел по размеру, получается, что в SDK_EXPORT попадает файл из .runs.

Если опираться на то, что Вы сказали:

Все .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 0]

Как я понял из Ваших предыдущих сообщений, во всех *.bmm находятся рам-блоки. Правильно ли я понимаю, что в не _bd находятся все рам-блоки, а в _bd дополнительно описаны ещё и те, которые предназначены для микроблэйза?

Оба .bmm описывают одни и те же Block-RAM-блоки, находящиеся в адресном пространстве микропроцессора (или -ов). System_bd.bmm содержит более подробную информацию о них - их двумерные адреса в ПЛИСе. Более подробно о BMM можно почитать в UG437.

[Krys 2]

Ага, спасибо, надо было мне лучше сразу спросить, где про это прочитать. Читать то я непротив, особенно когда в каком-то источнике можно найти краткий, чётко локализованный ответ.

[Krys 2]

Я похоже разобрался в своей проблеме с запуском из первого поста. Это у меня лыжи не ехали, я же новичок во встраиваемых системах ))) Правда за последнее время я уже похоже на многие грабли наступил, шишек набил, можно уже из новичков меня вычёркивать)

 

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

Предлагаю для новичков, кто ещё будет наступать на эти грабли, следующую инструкцию.

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

 

 

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

 

 

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

 

 

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

 

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

 

Если SDK не закрывался, то при нажатии на жучка:

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

 

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

 

Ну вот так, сумбурно маленько, конечно - тороплюсь, поздновато уже на работе, домой пора )) Но надеюсь поможет кому-то ) А то я долго голову с этим ломал, не мог до меня дойти великий тайный смысл этих разных конфигураций.