Jump to content
    

Dimonira

Свой
  • Posts

    462
  • Joined

  • Last visited

Reputation

0 Обычный

About Dimonira

  • Rank
    Местный
    Местный

Контакты

  • ICQ
    Array

Recent Profile Visitors

1,851 profile views
  1. Чтобы отмести версию неисправности железа, проверил ещё на двух других платах, в том числе одна из которых работала с версией до обновления - поведение абсолютно такое же. На двух ревизия чипа Y, на заведомо работающей - Z. Выходит дело только в софте. --- Нашёл! В фирмвари 1.27.0 есть ошибка (см. тут) - суть в том, что размер буфера приёма жёстко независимо ни от чего задавался в 1000 байт. Поэтому протоколы с более длинными пакетами, как у меня, не работают. Ошибка кроется в драйвере stm32f4xx_hal_eth - в строках 1183 и 1187 надо заменить 1000U на ETH_RX_BUF_SIZE. Я исключил файл драйвера stm32f4xx_hal_eth.c из компиляции проекта, скопировал его в Core/Src, переименовал и внёс правки. Проверил - работает! Вопрос снят.
  2. STM32F407VET6 их есть у меня. Брал когда-то в Элтехе про запас, сам пока не применял.
  3. Пока выяснил, что уже на входе ethernet_input, т.е. до разбора протоколов, данные пакета ущербные (похоже, недописанные/недопринятые до конца). И что исходники Lwip не менялись.
  4. Был проект работающего загрузчика по Ethernet в версии STM32CubeIDE 1.9.0 и пакете поддержки 1.26.1. Использую контроллер STM32F407VGT6 с внешним PHY, в качестве которого использую свич KSZ8863. Вышла новая версия STM32CubeIDE 1.10.1 и новый пакет поддержки 1.27.0. В изменениях, в частности, декларировалось "мощное" обновление поддержки интерфейса Ethernet - сделали драйвер PHY и пр. Решил "обновить" проект. Взял прежний ioc и на его основе сгенерил новый проект в новых версиях. Что-то там прокричало о новом вместо старого, не помню. С драйвером для KSZ8863 разобрался, остальное практически для меня мало поменялось. Итог: "обновлённый" проект не работает. В отладчике походил, оказалась проблема в приёме пакетов Ethernet по протоколу UDP в моём сервере загрузчика: с хоста передаётся пакет длиной 1214 байт, он принимается, длина правильная, но сами данные пакета искажены - последние 254 байта в пакете нулевые. Конечно, дальше ничего уже не работает. Беда в том, что непонятно почему это происходит. Изменение настроект стека, размеров буферов результата не дало. Может кто-то сталкивался с подобным? Стандартный сетевой обмен (пинги, например) работает. RTOS не используется, приём Ethernet без прерываний.
  5. ...продолжение опупеи. Убрал loopback, но радости это не принесло - передачи так и нет, хотя интерфейс уже вырубаться перестал, ведь буферов хватает (если в отладке не вставать). Далее в дело вступил осциллограф и помог: оказалось, что на PHY подавался GTX_CLK (такт передачи) частотой 100 МГц вместо 125. Тут я и вспомнил, что когда понижал частоту ядра NIOS и SDRAM до 100 (было 125), то забыл, что эта же частота идёт на PHY (её же, кстати, ещё надо переключать 125/25/2.5 в зависимости от скорости). В итоге пришлось ещё один выход в PLL организовать для 125 МГц. Далее пересобрал проект fpga и начал шить его в epcq (без прицепленного приложения). Когда прошивка завершилась и я нажал кнопку сброса, антивирус бодро сообщил мне, что в локальной сети появился новый клиент и показал mac-адрес моего девайса! Я понял, всё поехало! Я удивился, что приложение пошло, хотя я его не прошивал. Но потом понял, что оно же осталось в epcq с прошлого раза, я же полное стирание флеша не делал, а адреса в нём не поменялись, так что старое приложение вступилось (странно только, что SystemID то изменился, должно ли было запускаться?). На пинги плата отзывается. В итоге SSS работает, проверил, запустив в WSL Ubuntu (чтобы в Windows telnet не добавлять) команду telnet 192.168.81.99 30 Где 30 - номер порта, который обязательно указывать. SSS показал меню команд, далее попробовал вводить команды, мигать светодиодами и выкл/вкл "шоу" показа случайных чисел на семисегментном индикаторе (шоу - вывод случайных значений с периодичностью 50мс). Шоу, кстати включено по умолчанию, что помогает понять успешный запуск приложения. Всё работает, ура. Подсистему TSE (что я приводил выше) доработал - выкинул лишний pipeline. В результате это избавило от красноты таймингов после компиляции. В плане таймингов помог сам PHY RTL8211E - у него была включена задержка 1.5-2 нс по передаче и приёму. Так что с этим вообще не заморачивался. Констрейны задавал так (если кому интересно): create_clock -name CLK -period 50MHz [get_ports {CLK}] create_clock -name RXCLK -period 125MHz [get_ports {GMII_RXCLK}] derive_pll_clocks derive_clock_uncertainty set_clock_groups -asynchronous -group {CLK} -group {RXCLK} set_input_delay -clock RXCLK -max 2 [get_ports {GMII_RXD[*] GMII_RXDV GMII_RXER}] set_input_delay -clock RXCLK -min 1.2 [get_ports {GMII_RXD[*] GMII_RXDV GMII_RXER}] set_false_path -from [get_ports KEY[*]] set_false_path -from [get_ports SW[*]] set_false_path -to [get_ports LED[*]] set_false_path -to [get_ports ELED[*]] set_false_path -to [get_ports SEG[*]] set_false_path -to [get_ports DIG[*]] Последние шесть строчек для игнора кнопок/светодиодов.
  6. Во время танцев с бубном вокруг TSE и гуляниям по исходникам выяснилось что: 1. Под пакеты (как я понял, и принимаемые, и передаваемые, что странно - передача может заткнуть приём и наоборот, как в моём случае) выделяются буферы двух размеров: 128 байт под маленькие пакеты и 1536 байт под большие в количестве по 30 штук каждых. Дескрипторы буферов объединяются в связанные списки. Всё это делается в pktalloc.c: queue bigfreeq; /* big free buffers */ queue lilfreeq; /* small free buffers */ unsigned lilbufs = NUMLILBUFS; /* number of small bufs to init */ unsigned lilbufsiz = LILBUFSIZE; /* big enough for most non-full size packets */ unsigned bigbufs = NUMBIGBUFS; /* number of big bufs to init */ unsigned bigbufsiz = BIGBUFSIZE; /* big enough for max. ethernet packet */ #ifdef NPDEBUG PACKET pktlog[MAXPACKETS]; /* record where the packets are */ #endif Все эти константы задаются в ipport.h. В отладочном коде есть глобальный массив pktlog, где можно все буфера посмотреть в одном массиве. 2. Оказывается, что когда в корке TSE включена возможность loopback, в исходниках одновременно включается опция promiscuous (файл ins_tse_mac.c): /* enable MAC */ dat = ALTERA_TSEMAC_CMD_TX_ENA_MSK | ALTERA_TSEMAC_CMD_RX_ENA_MSK | mmac_cc_RX_ERR_DISCARD_mask | #if ENABLE_PHY_LOOPBACK ALTERA_TSEMAC_CMD_PROMIS_EN_MSK | // promiscuous mode ALTERA_TSEMAC_CMD_LOOPBACK_MSK | // promiscuous mode #endif ALTERA_TSEMAC_CMD_TX_ADDR_INS_MSK | ALTERA_TSEMAC_CMD_RX_ERR_DISC_MSK; /* automatically discard frames with CRC errors */ А это означает, что TSE будет принимать всё что оказывается на входе. У меня loopback был по недоразумению включен. 3. Исходя из 1 и 2 у меня получалось, что все буферы большого размера сразу расходовались на принимаемые пакеты, ибо плата включена в сеть, где куча компов, умных розеток (их MAC-адреса я и видел в принятых фреймах) и т.д. Тем более, что буферов всего по 30 шт. Тем более в пошаговом режиме отладчика! Когда я вставал на первой же точке останова, хоть и сразу в нужном месте, но уже список bigfreeq был наполовину израсходован. Надо отключать loopback! 4. Попутно заметил фичу выделения буферов в куче, если размер пакета превышает максимальный для списка bigfreeq (1536): PACKET pk_alloc(unsigned len) { PACKET p; if (len > bigbufsiz) /* caller wants oversize buffer? */ { #ifdef HEAPBUFS if ((p = pk_alloc_heapbuf (len)) == NULL) return NULL; #else return(NULL); #endif } else { if ((len > lilbufsiz) || (lilfreeq.q_len == 0)) /* must use a big buffer */ p = (PACKET)getq(&bigfreeq); else p = (PACKET)getq(&lilfreeq); if (!p) return NULL; } //... Но, как я понял, HEAPBUFS не определена (задаётся в ipport.h). Так что при больших размерах пакетов будет пшик. Дефайн HEAPBUFS убран условной компиляцией через определение NOT_USED (задаётся в редакторе BSP для "новых версий" Iniche стека). Там вообще много чего выкидывается интересного. И как можно вносить в ipport.h свои правки, если при перегенерации BSP всё пропадёт (как пропадают, например, мои добавки для PHY RTL8211E в файлы altera_avalon_tse.h/c, приходится их возвращать). Жаль не сделали "окна" для пользовательских правок как в студии для STM32. Пошёл убирать loopback. Продолжение следует...
  7. Доброго дня плисоводам. При разработке системы, указанной в сабже, возникли проблемы при запуске стандартного примера SSS (интерфейс с PHY - GMII). Некоторые подробности описывал тут, поэтому повторять не буду (отладка заработала). По началу не было ни приёма, ни передачи. Но, переделал схему (оказалось, расширенный режим MSGDMA вкдючать нельзя) системы и вроде начало как-то работать - приём вроде появился: ethernet-фреймы принимаются, смотрю в обработчике прерываний приёма, вижу mac-адреса реальных девайсов в домашней сети. А вот передача не идёт. Первый посылаемый пакет - дискавери от dhcp клиента, посылаемый dhc_request. В пошаговом режиме дохожу до выделения буфера с помощью udp_alloc, а оно завершается неудачей. В результате стек вырубает сетевой интерфейс и делает exit. Пытаюсь по шагам пройти до критического места, но не выходит. Функция udp_alloc вызывает pk_alloc, которая принимает требуемый размер буфера len=592 байта, но как только делается проверка размера, то len уже становится равным 1528. Подозреваю, что отладчик ловит вызов от приёмной ветки, там, как я понимаю, выделяется на приём пакета память исходя из размера MTU. После проверки размера вызывается getq, которая непосредственно пытается выделить память из каких-то свободных цепочек, но почему-то сразу нарывается на то, что свободных буферов уже нет, возвращает 0, ну а дальше я уже написал - в итоге exit. В чём может быть проблема? И вообще, какие настройки должны быть у MSGDMA? Может с ними что-то не так?
  8. Вот этого я и хочу избежать. По крайней мере, пока не пойму что и как делать. А чтобы понять что к чему, нужен готовый пример, желательно работающий. Как я писал выше, в версии 18.1 сгенерировать пример SSS невозможно. Что касается 20.1, то решение проблем я нашёл: оказывается, Альтера выпустила патч quartus-20.1std-0.08std-windows.exe, который решает всё тут описанное мной. Узнал я это тут. Кстати, там написано, что надо ещё в WSL Ubuntu установить wsl: sudo apt install wsl На всякий случай прикладываю патч сюда. Действительно, всё решается, причём правка makefile делается иначе, не как я делал (и не так как отвечает Erik по ссылке). Отладчик тоже запускается. quartus-20.1std-0.08std-windows.exe
  9. Привет мученикам Quartus. Задача: сделать работающий проект на отладочной плате Циклон-4/5 + SDRAM 32/64MB на NIOS-II + TSE + PHY RTL8211E. С железом проблем пока не обнаружено, а вот с софтом мучаюсь вторую неделю. Поскольку студия на основе BSP может родить только пустой проект, я решил собрать работающий пример на примере SSS. Но не тут то было. В версии квартуса 18.1 студия EDS вообще импотентна по части генерации примеров - в процессе генерации проекта что-то идёт не так и создаваемой папке студия даёт такие права, что сама не может потом достучаться до makefile-а. Решил найти последнюю версию, в которой ещё EDS, а главное, Niche-стек, не были выпилены. Этой версией оказалась 20.1. Устанавливал её в Windows 10 IoT Корпоративная LTSC. Какие проблемы удалось решить: 1. В Windows надо установить WSL версии 1. Точнее, нужна такая система, которая в отклике на команду "uname -r" выдаёт строку, содержащую слово "Microsoft" - именно так, с заглавной буквой. Дело в том, что используемые при генерации проектов скрипты, например, nios2-bsp и create-this-app используют для обнаружения WSL следующую конструкцию: uname=$(uname -r) if [[ $uname =~ "Microsoft" ]]; then _IS_WSL=1 windows_exe=.exe fi Поэтому, если установлена WSL версии 2, она может выдавать в отклике на команду "uname -r" что-то типа: 5.10.16.3-microsoft-standard-WSL2 Слово "microsoft" с маленькой буквы - скрипт не работает, проект примера создан не будет. Если установлена WSL версии 1, то отклик будет типа такого: 4.4.0-19041-Microsoft В принципе, не обязательно ставить WSL версии 1 - можно поправить скрипты, но кроме двух оговорённых могут быть и другие - нет гарантии, плюс часть скриптов сидят в архивах .jar. 2. После установки WSL и создания учётной записи (логин/пароль) для работы скриптов студии надо доустановить в Ubuntu две программы, которых изначально нет: make и dos2unix: sudo apt update sudo apt install make sudo apt install dos2unix и неплохо бы ещё: sudo apt dist-upgrade 3. При компиляции проектов в варианте Quartus 20.1 + NIOS2 EDS в случае возникновении ошибки компиляции приложения можно слегка отредактировать makefile и заменить строку (~340-я): APP_LDFLAGS += -msys-lib=$(call adjust-path-mixed,$(SYS_LIB)) на эту: APP_LDFLAGS += -msys-lib=$(SYS_LIB) Не силён в скриптах, но, видимо, эта проблема из той же оперы "пути и их названия". ИТАК, после всей этой борьбы с глюками, генерация примеров заработала и удалось сгенерировать BSP для своей платы и проект Simple Socket Server (SSS). Мало того, проект даже компилируется, правда после того, как подредактировал дефайны своего железа, они назывались не так как в примере. Так, в проекте приложения пришлось править файл tse_my_system.c в части названий регистров TSE и MSGDMA. А в файле led.c в части PIO светодиодов и семисегментного индикатора. Ещё добавил IP-адреса девайса и шлюза в simple_socket_server.h. а в функции get_serial_number (network_utilities.c) добавил фиксированный серийный номер, чтобы не вводить его в консоли: alt_u32 get_serial_number (void) { alt_u32 ser_num = 123456789;//0; Плюс в проекте BSP добавил в файл altera_avalon_tse.h константы для RTL8211E (там где для 88E1111 и др.): // Realtek RTL8211E enum { RTL8211E_OUI = 0x000732, RTL8211E_MODEL = 0x11, RTL8211E_REV = 0x5 }; А в файле altera_avalon_tse.c добавил в таблицу дефолтовых PHY свой (остальные, кстати, закомментировал): alt_32 alt_tse_phy_add_profile_default() { /* supported PHY definition */ /* ------------------------------ */ /* Realtek RTL8211E */ /* ------------------------------ */ alt_tse_phy_profile RTL8211E = { "Realtek RTL8211E", /* Realtek RTL8211E */ RTL8211E_OUI, /* OUI */ RTL8211E_MODEL, /* Vender Model Number */ RTL8211E_REV, /* Model Revision Number */ 0x11, /* Location of Status Register */ 14, /* Location of Speed Status */ 13, /* Location of Duplex Status */ 10 /* Location of Link Status */ }; #if 0 // ... // было для других PHY //... #endif alt_tse_phy_add_profile(&RTL8211E); return phy_profile_count; } Ко всему этому, заметил, что в Iniche есть процедура обнаружения подключенных PHY через интерфейс MDIO, на начинает поиск почему-то с адреса 0. А это, как я понимаю, броадкастовый адрес, значит любой PHY будет отвечать. В результате такого поиска обнаруживается два PHY, хотя оба ответа от одного и того же. А потом стек выводит предупреждение, типа два PHY на одном канале. Так что старт цикла поиска сделал не с 0, а с 1: alt_32 alt_tse_mac_get_phy(alt_tse_mac_group *pmac_group) { //... //... //... /* loop all valid PHY address to look for connected PHY */ for (phyadd = 0x01; phyadd < 0x20; phyadd++) { //... //... //... Вот теперь кажется всё, проект компилируется под моё железо. Однако дело упёрлось в отладку, после настройки конфигурации отладки, жму F11, происходит загрузка, но отладчик не может установить точку останова на main и, как я понял, подгрузить исходники: Видимо, опять что-то с путями? В начале выполнения отладки в консоли проскакивают красным цветом сообщения о каком-то файле (похоже, ассемблерном), но его физически нет: Пока идей как решить проблему нет. Может кто-то решил? Скопировал проект в среду квартуса 18.1 и запустил отладку. Там дошёл до передачи через MSGDMA (протокол ARP шлёт запрос), но она не идёт, встаёт на выделенном месте: Подозреваю, что может это связано с несовместимостью 18.1-20.1. Есть мысли? Я что-то выдохся, неделю шёл к получению компилирующегося примера SSS, но этого оказалось мало. Теперь заставить бы работать.
  10. Столкнулся первый раз. Есть лицензия из закромов, в ГУИ Quartus (версия 18.1) пока всё работало, но сам скрипты не использовал. Тут решил попробовать добавить кастомную плату Циклона 4 в Матлаб. Запустил тесты FIL и Turnkey, а они не проходят. Ошибка лицензии. Я подумал, что проблема с лицензией в Матлабе, но сейчас запустил скрипт не из Матлаба, а в созданных им исходниках - ошибка осталась. Выходит проблема с лицензией Quartus. Ошибка возникает при выполнении скриптом команды компиляции проекта "execute_flow -compile". Как порешать?
  11. Если бы это была просто ошибка, то её бы давно исправили, ибо она не в последней версии появилась, пользователей миллионы, а ошибка фатальная - контроллер не прошить. Конечно, многие шьют прямо из Студии и/или JLink-ом, но всё равно массовость имеет место быть. Серьёзно? На сайте никаких предупреждений об ограничении скачивания софта для России я не увидел. Ну, значит по признаку страны можно не проверять. Как на счёт языка системы? Русофобия к географии не привязана.
  12. Вот и я, прошил через JLink. Надо бы попробовать изменить страну в настройках системы. Лень однако...
  13. Похоже на то, что нам решили нагадить и не только не давать софт, но и ограничить его функционал: STM32CubeProgrammer подключается к STLink, видит контроллер, считывает его память, может стереть. НО, если попытаться что-нибудь записать в контроллер, то сразу после нажатия кнопки Download программа закрывается. Происходит это на разных компьютерах, и в версии 2.8 и в 2.10, остальные не пробовал. Кто-нибудь сталкивался?
  14. Санкции. Надо использовать VPN. Я в браузере плагин поставил.
×
×
  • Create New...