Jump to content

    

attaboy

Свой
  • Content Count

    106
  • Joined

  • Last visited

Community Reputation

0 Обычный

About attaboy

  • Rank
    Частый гость

Информация

  • Город
    Array

Recent Profile Visitors

552 profile views
  1. И правда есть. Переоценил мощь поисковых систем. Я бы сказал "Что-то есть, но не из перечисленного". Я так понимаю этот бит на тот случай, если пользователь прочитал не слово статуса - где и так все видно, а один байт. И если ошибка не в прочитанном, а в другом байте, устанавливается этот бит. Замороченно конечно, но вроде прояснилось.
  2. Ну это уже серьезный fault. Вряд ли при его наличии было бы нормальное выходное напряжение.
  3. Есть устройство, которое в принципе работает. Там установлен преобразователь питания IR38062M. Читаю регистры статусов через I2C - получаю значение 0x8001. В документации на преобразователь написано про статусы: Returns 1 byte where the bit meanings are: Байт 0: Bit <7> device busy fault Bit <6> output off (due to fault or enable) Bit <5> Output over-voltage fault Bit <4> Output over-current fault Bit <3> Input Under-voltage fault Bit <2> Temperature fault Bit <1> Communication/Memory/Logic fault Bit <0>: None of the above Байт 1: Bit <7> Output high or low fault Bit <6> Output over-current fault Bit <5> Input under-voltage fault Bit <4> Reserved; hardcoded to 0 Bit <3> Output power not good Bit <2:0> Hardcoded to 0 Получается у меня установлены биты "None of the above" (непонятно, что здесь имеется в виду) и "Output high or low fault" Читаю регистр 8Bh - READ_VOUT - там получается 1,011 В. В принципе как и положено. Начал разбираться в настройках VOUT_UV_FAULT_LIMIT и VOUT_OV_FAULT_LIMIT и появилось несколько вопросов: - Для вычисления величины VOUT_OV_FAULT_LIMIT приводится формула, в которой есть Vs (полагаю, что это Voltage sense). Непонятно, что брать в качестве Vs для расчетов. - В слове статусов есть Output over-voltage fault и Output high or low fault. В чем разница между этими двумя состояниями? - Также в наборе регистров есть STATUS_VOUT (0x7A), в котором содержатся коды сбоев, связанных с VOUT. Читаю этот регистр и получаю значение - 0х8040. Но нигде не нашел, что это значит. Есть ли у кого-нибудь документация, где раскрываются эти коды ошибок?
  4. Рассматриваю возможность использования интерфейса USER-K для передачи высокоприоритетных сообщений Aurora. В ядре Aurora при активации опции USER K появляется ещё один интерфейс AXI - s_axi_user_k. Информация по USER K в PG074 достаточно скудная. Понятно, что для отправки/получения USER-K сообщений нужно использовать соответствующую шину AXI. Но остается вопрос - как сообщение USER-K вставляется в общий поток Aurora? Дожидается завершения передачи текущего пакета или же отправляется немедленно, прерывая передачу обычного пакета? Насколько вообще целесообразно использование USER-K для передачи высокоприоритетных сообщений по сравнению с организацией двух очередей (низко и высокоприоритетной) для одного интерфейса AXI?
  5. Точно есть проблема со счетчиком cnt. Он почему-то в блоке always @ (posedge clk) встречается как с блокирующим присваиванием, так и с неблокирующим. Все присваивания в блоке always @ (posedge clk) должны быть неблокирующими (<=). Ну и там непонятна логика счета. Сначала счетчик безусловно инкрементируется (cnt = cnt + 1) а потом в case вдруг выставляются условия. Такого быть не должно - логика работы cnt должна определяться однозначно.
  6. Если названия сигналов не меняются, в принципе без разницы, как их добавлять - через скрипт или GUI. А если они поменялись, то через GUI тоже проблематично добавлять после синтеза. Был data_ack, а стал data_ack_1. Вроде похоже, но не факт, что повторяет поведение исходного сигнала. Поэтому по хорошему в любом случае нужно закреплять сигналы чере mark_debug, независимо от способа их подключения. Если сидеть и ждать, пока проект синтезируется и разведется, то конечно 40-50 минут - это ощутимо. Но для больших проектов как правило синтез и имплементация проходят "в фоне" на специально выделенных серверах. Запустил на ночь проект на сборку и пошел домой. Плюс минус 1-2 часа мало кого интересует. Ну или даже если днем запустил на сборку - все равно на время сборки проекта занимаешься другими делами и время не теряется. Вот например скрипт создания ila, которым я пользуюсь: В процессе создания скрипта конечно пришлось приложить некоторые усилия, чтобы он работал корректно. Но сейчас я задаю клоки, список интересующих сигналов, и все. Скрипт обладает некоторым интеллектом. Например, ширину шины определяет автоматически (в отличие от задания шины через GUI), если вдруг какой-то сигнал (кроме первого в списке) соптимизировался после синтеза, скрипт скажет об этом в лог-файле и продолжит работу (а если такое произойдет при создании ila через GUI - это ошибка). Этот скрипт подгружается другим скриптом, который у меня разворачивает проект и запускает все процессы. Поэтому я могу сделать несколько tcl с ila, и для каждого ila соберется своя имплементация. Это необходимо, когда все сигналы сразу не вмещаются в отладчик. Делаем один impl_run с о одним набором сигналов, а потом другой impl_run - с другим набором сигналов, и т.д. То есть в общем запускается один скрипт, который подгружает десяток других скриптов, в том числе и скрипты с ila, и на выходе выдает набор прошивок, которые хотелось получить - с разными ila, с разными стратегиями синтеза и имплементации и т.д. Очень удобно, но конечно такой подход оправдан для крупных проектов, где вычисления проводятся на специально выделенных машинах.
  7. Да. Но это бывает необходимо и при использовании GUI. (*mark_debug="true"*) - насущная директива отладки, независимо от используемого метода. Но ведь отладка в принципе предполагает изучение исходников и поиск потенциально проблемных мест. Можно конечно добавить в отладчик максимум сигналов в надежде на то, что там будет нужный, но этот метод работает только при околонулевой загрузке ПЛИС.
  8. Было значение HCD_SPEED_HIGH. Помянял на HCD_SPEED_FULL - и проблемная флэшка заработала! Для моего приложения это удовлетворительное решение проблемы - высокая скорость не требуется, нужна стабильность. Большое спасибо за помощь!!!
  9. Вообще самый надежный способ - изначально задавать все отладчики в скриптах. При некоторой сноровке это даже быстрее, чем через GUI. И не нужно каждый раз открывать отладчик, что-то удалять, добавлять, потом выяснять, что GUI Vivado все понял не так. Со скриптами все проще - подключил нужный список сигналов, пересобрал проект, и готово. Плюс появляется более глубокое понимание структуры проекта, что тоже важно для проектов сложнее "моргателя светодиодов".
  10. Да, скорость ограничивал до fs - по крайней мере поставил в файле usbh_conf.h: #define HOST_HS 0 #define HOST_FS 1 Результат не изменился. Не совсем понял - как поставить дополнительные выдачи в месте возникновения ошибок?
  11. Поставил debug level 3. Для проблемной флэшки в окне Terminal I/O наблюдаю такие сообщения: Сообщение ERROR: Control error повторяется много раз. Что значит Control error в сообщениях не раскрывается. Что с этим делать - тоже непонятно
  12. А в каких случаях вообще такое извращение нужно? Приходит мысль - чтобы обойтись без локального refclk. Но нет, чтобы восстановить rxclk, нужен какой-то опорный клок.
  13. Мои познания в STM и его экосистеме крайне поверхностны, поэтому несколько дополнительных вопросов: - Если поставить debug level 3 - где смотреть результаты, если не в отладчике? Я полагаю, что при уровне 3 будет выводиться большое количество сообщений об изменениях состояний и т.д. Но куда дальше эти сообщения будут отправляться? На плате для общения с внешним миром есть USB (который в этом случае будет нерабочим) и SWD для программирования. - Какие например таймауты могут нарушаться и где их можно подстроить?
  14. Немного перефразирую вопрос. Есть плата с микроконтроллером STM32F4 и USB PHY USB3315. Есть управляющая программа для микроконтроллера. USB инициализируется стандартной функцией void MX_USB_HOST_Init (void); Порт USB предназначен для подключения флэшек. Устройства определяются функцией MX_USB_HOST_Process(); В принципе почти все работает нормально, но есть флэшки, которые не определяются. Их немного, но они есть. Причем те, которые не работают, как правило не работают через раз. Но вот я нашел одну флэшку, которая стабильно не работает (а четыре других, которые у меня есть - стабильно работают). Решил провести эксперименты. Запускаю отладчик, ставлю брейкпоинт на MX_USB_HOST_Process(). В процессе пошагового выполнения наблюдаю за структурой hUsbHostHS (микроконтроллер работает как хост). device.is_connected = 0x01 gState = HOST_IDLE Вызывается функция: USBH_StatusTypeDef USBH_Process(USBH_HandleTypeDef *phost) В этой функции исполняется ветка: switch (phost->gState) { case HOST_IDLE : if (phost->device.is_connected) { /* Wait for 200 ms after connection */ phost->gState = HOST_DEV_WAIT_FOR_ATTACHMENT; USBH_Delay(200U); USBH_LL_ResetPort(phost); #if (USBH_USE_OS == 1U) phost->os_msg = (uint32_t)USBH_PORT_EVENT; #if (osCMSIS < 0x20000U) (void)osMessagePut(phost->os_event, phost->os_msg, 0U); #else (void)osMessageQueuePut(phost->os_event, &phost->os_msg, 0U, NULL); #endif #endif } break; Наблюдаю за изменением phost->gState. Сначала происходит изменение из HOST_IDLE в HOST_DEV_WAIT_FOR_ATTACHMENT (как и должно быть согласно коду), а после USBH_LL_ResetPort(phost); состояние меняется на HOST_DEV_ATTACHED (для всех флэшек). А вот после break для нормальных флэшек состояние HOST_DEV_ATTACHED сохраняется, а для "ненормальной" - меняется на HOST_DEV_DISCONNECTED. Флэшка, которая не работает - USB3.0, но в наборе работающих есть как USB2.0, так и USB3.0. Все флэшки отформатированы под FAT32 и на обычном компьютере читаются нормально. Пока такие результаты исследований - причина отказа одной из флэшек непонятна.
  15. Есть микроконтроллер STM32F4, к нему подключен(а) USB PHY USB3315. Задача - необходимо прочитать регистры USB3315, в частности Vendor ID и Product ID - 0x00 - 0x03. Работаю в IAR IDE 8.50.9, для общения с USB используется HAL. Вопрос: как прочитать вышеуказанные регистры с помощью HAL? Не нашел таких низкоуровневых функций у HAL.