Перейти к содержанию
    

GAYVER

Свой
  • Постов

    195
  • Зарегистрирован

  • Посещение

Репутация

2 Обычный

Информация о GAYVER

  • Звание
    Частый гость
    Частый гость

Старые поля

  • skype
    Array

Контакты

  • Сайт
    Array
  • ICQ
    Array

Посетители профиля

2 348 просмотров профиля
  1. добрый день, товарищи где взять примеры работы с nIRQ на голом железе? в примерах от хилых вроде ничего не нашел, в уг585 конкретики тоже не много... с SPI прерываниями вроде более-менее наловчился работать. у каждого драйвера вендором уже написан свой "главный" обработчик, который сбрасывает прерывание и производит необходимые манипуляции со статистикой и прочим. плюс есть доступ к "софтовым" обработчикам, которые подключаются в соответствующие поля структуры драйвера. плюс можно назначить коллбэки - как я понимаю, это точка выхода из обработчика, в которой можно вернуть управление не в точку вызова, а перескочить на какую то другую функцию а как быть с PPI? к которым и отсносится nIRQ. где лежит его обработчик? как до него добраться, как модифицировать? ну, или как написать и подключить свой, и что в нем обязательно должно быть?
  2. оптимизация отключена. это раз. как посмотреть разрешения на оптимизацию отдельно взятого файла я так и не нашел. два - компилятор при прогоне кода при любых раскладах должен ругаться на использование не объявленной переменной. этого не будет только в том случае, если цикл вырождается в 1 прогон. т.е. просто в однократное линейное выполнение операторов в теле цикла. но этого не может быть потому, что верхняя граница цикла - параметр, передаваемый в функцию. который является ненулевой константой. по крайней мере на этапе отладки. в дальнейшем будет переменной
  3. а как быть со 2 пунктом? где связь между счетчиком цикла и в невозможности включить станадарнтую библиотеку в другом конце кода?
  4. Не прокатило... Но таки спасибо - сходим в этом направлении 🙂
  5. а не подскажете тогда - где смотреть эти настройки? апд функция возвращает не совсем то, что я ожидаю. собственно поэтому и полез во внутрянку - смотреть что там происходит
  6. В "дебаг конфигкрейшен" не нашел никаких настроек а-ля "оптимизировать". Да и за несколько месяцев отладки, думаю, уже бы заметил подобное поведение отладчика... До этого момента все было как и положенно - линейный сишный код, линейно по нему проходим апд в настройках си билдера оптимизейшен левел - 0. Т.е. выключен
  7. По долгу службы пришлось делать работу штатного программиста и писать драйвер и программу под цинк 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" в самописной библиотеке, в совершенно другом файле, написанном для работы с микрухой физики. Самописная библиотека до этого была проверена и отлажена. Проверки на двойные включения либ в ней есть. И, собственно, второй вопрос - это что за хрень??? Где связь между необъявленной переменной и включением библиотеки в другом конце кода????? Ну и главный вопрос - куда бежать и что делать? Я сейчас что-то даже поисковый запрос для гугла не могу составить... Фиг знает что у него спрашивать, чтобы адекватный ответ получить
  8. отписываюсь что это было Непропай подтяжечного резистора на МИО2... Который отвечает за режим работы JTAG - каскадный или независимый. Когда становились щупом на резистор, чтобы посмотреть на нем напрягу - поддавливали резюк, контакт улучшался, он нормально садил МИО2 в землю, задавая, как и положено, каскадный режим. Ну и, соответственно, показывая на осциле положенный ноль. А в оборванном состоянии на МИО2 висела единица, задавая при загрузке независимый режим JTAG (при котором ДАП и ТАП в разных цепочках). Плюс адское совпадение с напаянными проводами... В наших краях в эти дни было весьма жарко - температура за бортом в районе 38 градусов. Кондер старый, не справлялся. И в помещении тоже было жарковато. Плюс вокруг компы, аппаратура, итд. А в день "Ч", когда напаялись и отвалился проц, температура упала до 25 градусов на улице. В общем пришли к выводу что пока было жарко - резюк контачил нормально. А когда похолодало - отвалился
  9. Ситуация. Недавно получили самодельную плату с 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 от ПЛИСины, и исчезновением проца? Понятно что "после" не означает "вследствие", но в целом какое то подозрительное совпадение. Пайка была выполнена аккуратно, без перегревов и соплей. На сопли под микроскопом специально проверял, т.к. там рядом с ногой клока - питание микрухи
  10. оставлял это как последнее средство... очень не хотелось переписывать все :( апд а за тонкости применения паковки массивов не поясните? пока понял только то что упакованный используется для экономии и является чем то вроде "список ссылок на структуры-черные ящики". по типу как строка это набор символов. список из элементов, каждый из которых отдельный контейнер, содержащий код символа
  11. Добрый день. Дано: 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" не совсем понимаю связь упакованных/распакованных массивов с данной ситуацией. как, впрочем, и не совсем понимаю логику и особенности применения таких массивов :)
  12. upd вместе с опытным системщиком пришли к выводу что эти выбросы дает фильтр, стоящий на плате между ДДС и ПЛИС
×
×
  • Создать...