GAYVER

добрый день, товарищи где взять примеры работы с nIRQ на голом железе? в примерах от хилых вроде ничего не нашел, в уг585 конкретики тоже не много... с SPI прерываниями вроде более-менее наловчился работать. у каждого драйвера вендором уже написан свой "главный" обработчик, который сбрасывает прерывание и производит необходимые манипуляции со статистикой и прочим. плюс есть доступ к "софтовым" обработчикам, которые подключаются в соответствующие поля структуры драйвера. плюс можно назначить коллбэки - как я понимаю, это точка выхода из обработчика, в которой можно вернуть управление не в точку вызова, а перескочить на какую то другую функцию а как быть с PPI? к которым и отсносится nIRQ. где лежит его обработчик? как до него добраться, как модифицировать? ну, или как написать и подключить свой, и что в нем обязательно должно быть?

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

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

Не прокатило... Но таки спасибо - сходим в этом направлении 🙂

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

В "дебаг конфигкрейшен" не нашел никаких настроек а-ля "оптимизировать". Да и за несколько месяцев отладки, думаю, уже бы заметил подобное поведение отладчика... До этого момента все было как и положенно - линейный сишный код, линейно по нему проходим апд в настройках си билдера оптимизейшен левел - 0. Т.е. выключен

По долгу службы пришлось делать работу штатного программиста и писать драйвер и программу под цинк 7к. До этого момента с витисом дел не имел. и на сях писал толкьо простенькие скетчи для ардуины. И, собственно, в процессе отладки столкнулся с несколькими непонятными моментами. 1. Запускаю дебагер, пошагово выполняю программу. При входе в функцию XEmacPs_BdRingCreate (библиотека "xemacps_bdring.c" драйвера emacps) наблюдаю следующую картину - пошаговый отладчик в линейно написанном коде скачет по строкам как хочет. Условно последовательность выполнения строк может быть - 1-2-3-4-5-10-6-7-15-20-15-16-11-25, итд итп. При том что выполнятся они должны линейно - 1-2-3-4-...-20-21-23-... (ну, за исключением цикла). Код в строчках (если на нее прыгнули) выполняется, переменные переписываются. Вопрос в том что значения этих переменных из-за скачков - не верные. Собственно вопрос - это что за фигня? 2. В этой же функции присутствует цикл на 2 строчки - заполнение адресов цепочки дескрипторов. Ввиду первого пункта этот цикл не выполняется от слова совсем. Счетчик цикла не наращивается. Но было замечено следующее - при удалении объявления переменной счетчика цикла, компилятор не ругается на наличие необъявленной переменной. Компилятор ругается на то что не может найти подключаемую стандартную библиотеку "xil_types.h" в самописной библиотеке, в совершенно другом файле, написанном для работы с микрухой физики. Самописная библиотека до этого была проверена и отлажена. Проверки на двойные включения либ в ней есть. И, собственно, второй вопрос - это что за хрень??? Где связь между необъявленной переменной и включением библиотеки в другом конце кода????? Ну и главный вопрос - куда бежать и что делать? Я сейчас что-то даже поисковый запрос для гугла не могу составить... Фиг знает что у него спрашивать, чтобы адекватный ответ получить

отписываюсь что это было Непропай подтяжечного резистора на МИО2... Который отвечает за режим работы JTAG - каскадный или независимый. Когда становились щупом на резистор, чтобы посмотреть на нем напрягу - поддавливали резюк, контакт улучшался, он нормально садил МИО2 в землю, задавая, как и положено, каскадный режим. Ну и, соответственно, показывая на осциле положенный ноль. А в оборванном состоянии на МИО2 висела единица, задавая при загрузке независимый режим JTAG (при котором ДАП и ТАП в разных цепочках). Плюс адское совпадение с напаянными проводами... В наших краях в эти дни было весьма жарко - температура за бортом в районе 38 градусов. Кондер старый, не справлялся. И в помещении тоже было жарковато. Плюс вокруг компы, аппаратура, итд. А в день "Ч", когда напаялись и отвалился проц, температура упала до 25 градусов на улице. В общем пришли к выводу что пока было жарко - резюк контачил нормально. А когда похолодало - отвалился

Ситуация. Недавно получили самодельную плату с 7015 на борту. Один день пытался оживить в железе написанную ранее программу. В смысле дебажил в Витисе на железке. Дошел до момента настройки микрух физики ETH (на борту их две). Возникла необходимость проверить что физически гоняется по МДИО. Подлезть 2 щупами осцила было нереально, поэтому было принято решение напаять на лапы МДИО проводки и подцепиться к ним. Напаяли. После чего отвалился проц... В JTAG цепочке видно только плисину. Арм пропал. Третий день в гугле и мануалах. Результата ноль. Первое предположение что проц уходит в защиту и не доходит до момента включения DAP. Очередность и время выставления питаний в норме - промеряли. Приход сброса тоже в соответствие с требованиями. Повторная подача сбросов (POR/SRST) ничего не дает. BOOT_MODE - каскадный JTAG. Во флэшке прошит образ из ФСБЛ/прошивка_ПЛ/программа_проца. 99% уверенности что прошитый ФСБЛ не рабочий, т.к. прошивали флэшку тем что было под рукой (тестировали "прошивочный" ФСБЛ с программной заглушкой на прошивку в JTAG режиме, т.к. изначально плата изготовлена для старта в QSPI-mode и перемычек на JTAG -mode не было предусмотрено). Потом уже пришлось напаиваться на BOOT_MODE пины, чтобы переключиться в загрузку JTAG, чтобы исключить влияние прошитого загрузчика Есть вопрос по поводу требования из пункта 6.2.3. (уг585) - чтобы к моменту подачи питания на ПЛЛ, ПС_ЦЛК от внешнего генератора уже был стабилен. Такое требование есть, но что будет если оно не выполняется - не написано. А оно у нас сейчас не выполняется - клок появляется на пару мс позже чем на ПЛЛ подается питание. Но чтобы исключить это - включили обход ПЛЛ в BOOT_MODE. К тому же в первый день все прекрасно работало и без обхода и на таких временах включения... еще было замечено - надпись на ПЛИСине местами потемнела... Изначально была выполнена блестящей "желтой" "краской", которая хорошо читалась. Сейчас в правом верхнем углу эта краска сильно потускнела. По расположению это как раз МИО проца... В итоге куда бежать и что делать??? А главное - где связь между напайкой 2 сантиметровых проводов на МДИО микрухи, расположенной сантиметрах в 5 от ПЛИСины, и исчезновением проца? Понятно что "после" не означает "вследствие", но в целом какое то подозрительное совпадение. Пайка была выполнена аккуратно, без перегревов и соплей. На сопли под микроскопом специально проверял, т.к. там рядом с ногой клока - питание микрухи

попробую как вариант. спасибо

благодарю

оставлял это как последнее средство... очень не хотелось переписывать все :( апд а за тонкости применения паковки массивов не поясните? пока понял только то что упакованный используется для экономии и является чем то вроде "список ссылок на структуры-черные ящики". по типу как строка это набор символов. список из элементов, каждый из которых отдельный контейнер, содержащий код символа

Добрый день. Дано: 1. ВХДЛ модуль, внутри которого есть дженерик параметр Х (C_ARD_ADDR_RANGE_ARRAY) типа "двумерный массив" (описывается в отдельном пэкэдже, подключается как библиотека) 2. ВЕРИЛОГ модуль внутри которого подключается ВХДЛ модуль. Задача: передать параметр Х (C_ARD_ADDR_RANGE_ARRAY) типа "двумерный массив" из верилог модуля в вхдл модуль. В идеале задать значение через константу в верилог модуле и при инициализации вхдл модуля присваивать параметру значение этой константы. Но на безрыбье и хотя бы в процессе инициализации модуля задавать это значение... ЗЫ Синтезатор вивадовский. Пробовал разный синтаксис, на все ругается. В частности запись localparam [0:63] C_ARD_ADDR_RANGE_ARRAY [0:7]={ 64'h0000000000000200,64'h00000000000003FF, 64'h0000000000000400,64'h00000000000005FF, 64'h0000000000000600,64'h00000000000006FF, 64'h0000000000000700,64'h00000000000007FF} результат - "parameter with unpaked dimension is only allowed in SV" не совсем понимаю связь упакованных/распакованных массивов с данной ситуацией. как, впрочем, и не совсем понимаю логику и особенности применения таких массивов :)

upd вместе с опытным системщиком пришли к выводу что эти выбросы дает фильтр, стоящий на плате между ДДС и ПЛИС

вроде тема по смыслу в эту ветку подходит. если нет - перенесите. ситуация - в системник на ПСИ вставляется плата с плисиной. плисина периодически стучится в память в ДМА режиме. передача идет пакетами по 64 данных. в процессе передачи периодически происходит дисконнект "цели". не задержка в выделении шины по запросу, а именно "дисконнект с данными" в процессе передачи пакета. собственно вопрос - почему и куда копать? есть предположение что это более приоритетное системное устройство стучится в шину и арбитр нас отключает. но это только гипотеза. как работает арбитр - пока понятия не имеем. как и в целом за тонкости организации ПСИ :). пока только начали разбираться

Нет, коллеги не с времянками столкнулись. Они работали через профили. При старте системы контроллер заполнял все настроечные регистры (в том числе и регистры профилей) через последовательный интерфейс. Потом в процессе работы нужный профиль выбирали через отдельные пины ДДСки. И параллельный интерфейс и режим модуляции с параллельного порта - это разные вещи, не связанные между собой никак. Кроме того что используют параллельный порт

Они не связаны. По крайней мере логически. PARALLEL PORT TIMING это про режим доступа к внутренним регистрам х00-1В (CFR1? CFR2, итд). При этом с параллельной шины используется только часть бит (адрес/данные/стробы). А параллельная модуляция - все биты параллельной шины идут напрямую в регистры ядра - амплитуды-частоты-фазы. Не совсем понял что тут имеется в виду под плавностью. В свете первого предложения - то что по параллельной шине идет несколько передач (1 значение - 2 или 4 передачи, в зависимости от настройки) с новым значением, но применяются они не когда будет принято последнее, а после окончания каждой передачи?

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

Стоит задача запустить модуляцию с параллельного порта на данной ДДСке. Она управляется с ПЛИСины. Контроллер в ПЛИСине на старте заполняет настроечные регистры и регистры ядра - амплитуды-частоты-фазы. Частота 756МГц, фаза нулевая, а амплитуда в процессе работы изменялась - через параллельный порт насовывались то синусоида, то ступенчатые переключения. и в процессе работы появляются периодические тычки. Допустим на границе 2 соседних уровней амплитуды - плавное, на несколько периодов, увеличение амплитуды ВЫШЕ уровня, на который переключаемся, и такое же плавное опускание до этого нового уровня (см. рис). Тычки появляются не на каждом переключении. На синусоиде тоже бывают подобные выбросы посреди синусоиды. Появление от прошивки к прошивке в разных местах (в разные моменты переключения). Но в пределах одной прошивки стабильно в одном и том же месте (на синусоиде - в одном месте в рамках периода, на ступенчатом переключении - на одних и тех же переходах) собственно вопрос - что это, и как с этим бороться? зы при работе с профилями, в данной ДДСке, старшие товарищи столкнулись с тем, что в момент переключения профиля (выставление кода профиля на 4 пина), ДДСка переключалась с лагом. Допустим был выставлен код "0011". ДДСка сначала видела его как "0010", переключалсь на 2 профиль и только потом добегал нулевой бит и код воспринимался как "0011". Т.е. имел место некий рассинхрон бит на шине. Собственно мое предположение касательно параллельной шины был такое же - имеет место разбежка бит. В момент переключения где то в старших разрядах приходят единицы от нового значения, наслаиваются на старое и дают выброс, который больше нового значения. Которое, в свою очередь, больше чем было старое. На следующем такте шина выравнивается, на ней стабильное новое значение и диаграмма приходит в соответствие новому значению. Только не совсем понятно - почему изменение плавное, на несколько периодов несущей... ззы опора ДДСки 2ГГц, соответственно внутренняя рабочая частота - опора/16 - 125Мгц. ДДСка настроена на работу по фронту рабочей частоты (а не по ИО_апдейт). Т.е. значения с шины передаются в регистры на каждом такте

это понятно что mcs это не mb 11.0. но хотя бы направление поиска задано. может быть в очередном ПГ наткнусь и на требования к чистому МБ. ну или в даташите на него дочитаюсь до нужной строчки. а пока метод научного тыка показывает что и в чистом МБ есть аналог ИО_модуля, в котором что-то жестко прописано

вы оказались правы. в ПГ116 (MicroBlaze MCS v3.0) был такой пунктик: I/O ModuleThe I/O Module core is a light-weight implementation of a set of standard I/O functions commonly used in a MicroBlaze processor sub-system. Detailed information about the I/O Module core can be found in the I/O Module Product Guide (PG111) [Ref 5]. The I/O Module core registers are mapped at address 0x80000000, and the I/O Bus is mapped at address 0xC0000000-0xFFFFFFFF in the MicroBlaze memory space. The fixed I/O Module parameter values can be found in Table 4-3. Получил запрос на аксёвой шине, сейчас буду подгонять адреса. Спасибо за заданное направление поиска :)

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

Микроблейз из тестового примера был добавлен в бОльший проект. Для связи с нашими местными акси устройствами наружу с интерконнекта был вытащен один мастер инфтерфейс, который замаплен на адрес 0x20000000. Задача - достучаться до внешней памяти через этот интерфейс. В сишную тестовую программу вставил команду чтения с этого адреса (адрес взят как дефайн базового адреса этого мастер интерфеса из "xparameters.h"). Результат - на выходе микроблейза появляется чтение по этому адресу ("внешнее" акси) но не на порту акси-данных, а на порту внутренней памяти, висящей на LMB шине. При этом, несмотря на несовпадение адресов, стоящий внутри блока памяти декодера-"маскировщика" и в целом вылета адреса за доступный диапазон памяти данных микроблейза, ответ оттуда приходит #include "xparameters.h" //Библиотека с параметрами IP-блоков #include "xgpio.h" //Библиотека с функциями GPIO #include "xil_io.h" #include "xil_testio.h" XGpio gpio; //Создаем "программную" модель GPIO int main(){ u32 i = 0; //используем для задержки u32 led = 0; //состояние светодиода u32 pr=XPAR_M02_AXI_0_BASEADDR; //+0x10000000 u32 pr2; u32 cons=6; int err=3; XGpio_Initialize(&gpio, XPAR_GPIO_0_DEVICE_ID);//Находим и инициализируем GPIO xil_printf("Hello, world!!!");//Автоматически цепляется Uartlite и выводит сообщение err=Xil_TestIO32(XPAR_M02_AXI_0_BASEADDR, 4, cons, 0, 0); while(1==1){ //Бесконечный цикл мигания i++; //увеличиваем счётчик if(i == 1000){//Если достигнуто значение 1_000_000 led = !led;//Инвертируем состояние светодиода i = 0;//Сбрасываем сётчик XGpio_DiscreteWrite(&gpio, 1, led);//Записываем состояние светодиода в GPIO pr2=Xil_In32(pr); pr=pr+4; //xil_printf(pr2); } } return 0; } Плюс еще запользовал команду тестирования ввода-вывода. Результат тот же - вместо внешнего акси запросы уходят на внутреннюю память данных. Вопрос - где я не прав?

вопросы вроде задал - как отдебажить С-код без платы, почему не идет моделирование. цели - научиться работать с МБ. статья шикарна - более подробных и четких описаний я еще не видел. косяк в том, что HW часть и так не проблема, а SW часть не вполне соответствует исходным задачам