Still Enemy 0 13 марта, 2015 Опубликовано 13 марта, 2015 · Жалоба Дано: есть ПЛИС на базе МК stm32105. К ней прикручен usb, программно поднят cdc по примерам от st и допилены операции приёма/передачи. В неопределённый момент usb кабель выдергивается(возможно даже в момент передачи/приёма, но это не суть). Через некоторое время подключается обратно. Найти: 1)как программно отлавливать отключение usb кабеля? что при этом не плохо бы сделать? 2)как собственно программно отлавливать обратно подключенный кабель? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Still Enemy 0 14 марта, 2015 Опубликовано 14 марта, 2015 · Жалоба Вообще ни у кого ни одной идеи нет? Никто не сталкивался с такой проблемой? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
smalcom 0 14 марта, 2015 Опубликовано 14 марта, 2015 · Жалоба VBUS вообщето пропадает. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
toweroff 1 14 марта, 2015 Опубликовано 14 марта, 2015 · Жалоба VBUS вообщето пропадает. если куда нужно подключен ;) а то просто на питание вешают Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
A. Fig Lee 0 14 марта, 2015 Опубликовано 14 марта, 2015 · Жалоба В ст шной библиотеке есть ивенты и на дисконнект и на ресет и так далее Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
toweroff 1 14 марта, 2015 Опубликовано 14 марта, 2015 · Жалоба В ст шной библиотеке для филпсов не видел... error, sof, reset, power, suspend, resume... disconnect не видел корки разные, но события-то должны быть? покажите Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Still Enemy 0 16 марта, 2015 Опубликовано 16 марта, 2015 (изменено) · Жалоба В ст шной библиотеке есть ивенты и на дисконнект и на ресет и так далее Хорошо, я глянул в дебаге как что происходит при отключении/включении кабеля 1 подключение кабеля: после прерывания почему то сваливается в Handle Suspend Interrupt, затем Handle Reset Interrupt->Handle Enumeration done Interrupt->Handle Reset Interrupt->Handle Enumeration done Interrupt. Всё хорошо, устройство определилось 1 отключение кабеля: кидает USBSUSP в регистре OTG_FS_GINTSTS и собственно обрабатывается Handle Suspend Interrupt. 2 подключение: Handle Suspend Interrupt->Handle Reset Interrupt->Handle Enumeration done. Но устройство не определяется как положено, а висит как Unknown Device. Все последующие подключения/отключения никаких прерываний не кидают. И тут самое интересное, что в обработчике прерываний есть Handle Connection event Interrupt и Handle Disconnection event Interrupt, но в эти обработчики программа не попадает за всё то время, в которое я делал эти манипуляции. Если вы знаете, что есть эти ивенты, то возможно вы знаете как ими пользоваться? Знаете почему при отключении сваливается в Handle Suspend Interrupt. Расскажите пожалуйста или скажите как поправить, что бы всё работало. Изменено 16 марта, 2015 пользователем Still Enemy Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Still Enemy 0 16 марта, 2015 Опубликовано 16 марта, 2015 · Жалоба Я полазил по коду. В обработчик Connection/Disconnection event Interrupt программа в действительности и не может пройти, ибо замаскированы SRQINT и OTGINT. Хотя собственно эти обработчики, кроме как сброс бита прерывания, ничего не делают. Почему входит в Suspend mode тоже понятно: Выдержка из usb nutshell. Вход в Suspend Mode Устройство USB приостанавливается (переходит в режим Suspend), когда на шине нет активности более чем 3.0 мс. В течение следующих 7 мс устройство должно отключиться, и не потреблять ток больше, чем заданный ток suspend. Таким образом, через 10 мс после прекращения активности шины ток потребления от неё не должен превышать suspend current. Для поддержания состояния соединения к приостановленному хабу или хосту, устройство во время режима Suspend должно все еще предоставлять питание на pull up нагрузочный резистор, определяющий выбор скорости. Но всё равно не понятно чего не хватает устройству для работы... Почему то при повторном подключении кабеля обрабатывается один раз Handle Reset Interrupt->Handle Enumeration done, а не два раза как при первом соединении. Хотя почему кидает USBSUSP при первом подключении кабеля, так и не стало ясно. Так же почему то перестало кидать прерывание USBSUSP при отключении кабеля, чудеса... И еще не понятно, почему не формируются прерывания при подключении/отключении кабеля после второго подключения кабеля. Вопросов много, ответов нет... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
toweroff 1 16 марта, 2015 Опубликовано 16 марта, 2015 · Жалоба А устройство после отключения кабеля остается с включенным Pullup к D+? Возможно, там собака порылась Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Still Enemy 0 16 марта, 2015 Опубликовано 16 марта, 2015 (изменено) · Жалоба А устройство после отключения кабеля остается с включенным Pullup к D+? Возможно, там собака порылась Возможно, завтра попробую на работе. Но в usb nutshell написано обратное. Или я не правильно понял? Выдержка из usb nutshell. Вход в Suspend Mode Устройство USB приостанавливается (переходит в режим Suspend), когда на шине нет активности более чем 3.0 мс. В течение следующих 7 мс устройство должно отключиться, и не потреблять ток больше, чем заданный ток suspend. Таким образом, через 10 мс после прекращения активности шины ток потребления от неё не должен превышать suspend current. Для поддержания состояния соединения к приостановленному хабу или хосту, устройство во время режима Suspend должно все еще предоставлять питание на pull up нагрузочный резистор, определяющий выбор скорости. Изменено 16 марта, 2015 пользователем Still Enemy Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Still Enemy 0 17 марта, 2015 Опубликовано 17 марта, 2015 · Жалоба А устройство после отключения кабеля остается с включенным Pullup к D+? Возможно, там собака порылась Пробовал софтварно отключать подтяжку, после отключения кабеля кидает HardFault_Handler в startup_stm32f105xc.s Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
smalcom 0 18 марта, 2015 Опубликовано 18 марта, 2015 · Жалоба во. значит по событию ПО пытается вызвать неопределённый обработчик. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Still Enemy 0 18 марта, 2015 Опубликовано 18 марта, 2015 · Жалоба во. значит по событию ПО пытается вызвать неопределённый обработчик. Я на самом деле просто делал видимо не правильно. Я подтяжку вырубал с помощью регистра GCCFG и сбрасывал бит VBUSBSEN. После чего вылетало Hard Fault. Я почитал, правильно было сбрасывать потяжку софтаврным дисконектом в регистре DCTL выставлял единицу в бит SDIS. Ничего не поменялось кароч. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Still Enemy 0 21 мая, 2015 Опубликовано 21 мая, 2015 (изменено) · Жалоба Хочу поднять старую тему, ибо я решил проблему. Может быть это кому и поможет. Не знаю как у других, но у меня вылетал Hard Fault, после функции free(), собственно сразу же после повторного присоединения кабеля. Так что её тупо надо закомментить, потому как она смысловой нагрузки не несёт(только отрицательную нагрузку). Вызов этой функции лежит в usbd_cdc.c в функции USBD_CDC_DeInit: static uint8_t USBD_CDC_DeInit (USBD_HandleTypeDef *pdev, uint8_t cfgidx) { uint8_t ret = 0; /* Open EP IN */ USBD_LL_CloseEP(pdev, CDC_IN_EP); /* Open EP OUT */ USBD_LL_CloseEP(pdev, CDC_OUT_EP); /* Open Command IN EP */ USBD_LL_CloseEP(pdev, CDC_CMD_EP); /* DeInit physical Interface components */ if(pdev->pClassData != NULL) { ((USBD_CDC_ItfTypeDef *)pdev->pUserData)->DeInit(); //USBD_free(pdev->pClassData); pdev->pClassData = NULL; } Примерно так должно быть. Причина глюка проста: по задумке разработчиков HAL драйверов, указатель pdev->pClassData должен освобождаться из динамической памяти функцией free, хотя никакими функциями типа calloc, malloc память не выделялась. Да и вообще в данных драйверах никакого управления памятью нет. Так что будет достаточно строчки pdev->pClassData = NULL, чтобы всё работало! Изменено 21 мая, 2015 пользователем Still Enemy Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 123 21 мая, 2015 Опубликовано 21 мая, 2015 · Жалоба Нет, так лучше не чинить. Если потом все же по каким-то причинам захочется динамического выделения, то пользователь пойдет править USBD_malloc и USBD_free, не подозревая, что вызов USBD_free закоменнтирован. И получит утечку памяти. Так что лучше закомментировать вызов free(). Ну а то, что останется вызов лишней пустой функции - так такого Г в этом коде навалом, никто и не заметит несколько лишних байтов. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться