Димон Безпарольный 2 21 сентября, 2016 Опубликовано 21 сентября, 2016 · Жалоба Проблема возникает когда контроллер что - то выдает по CDC и тут вы отрубаете шнур. Все виснет колом и ресетится по IWDG(в моем случае). Ковырял CDC HAL - функции HAL_PCD_ConnectCallback(hpcd); и HAL_PCD_DisconnectCallback(hpcd); не вызываются. Пробовал читать USBx->GINTSTS: USB_OTG_GlobalTypeDef *USBx; if (USBx->GINTSTS & 0x20000000U) { Dummy = 78; } if (USBx->GINTSTS & 0x40000000U) { Dummy = 87; } Биты 30 ( SRQINT) и 29(DISCINT) стоят в нулях. Потом нарвался на это: Note: Only accessible in host mode. Т.е. нужный мне бит 29 работает только в host режиме. У меня - Device. Что делать? Может кто подскажет? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Wasserati 0 22 сентября, 2016 Опубликовано 22 сентября, 2016 · Жалоба Для начала можно попробовать понять что вообще происходит при отключении: hardfault, зависание на определенном участке кода или еще что-то. Скорее всего авторами стека ситуация разрыва соединения не предусмотрена вообще. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Димон Безпарольный 2 22 сентября, 2016 Опубликовано 22 сентября, 2016 · Жалоба Для начала можно попробовать понять что вообще происходит при отключении: hardfault, зависание на определенном участке кода или еще что-то. Скорее всего авторами стека ситуация разрыва соединения не предусмотрена вообще. Не попадант он ни в одну ловушку. В hardfault тоже. Я не умудрен в отладчике - толком не знаю как посмореть где виснет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
klen 1 22 сентября, 2016 Опубликовано 22 сентября, 2016 · Жалоба я проверяю вот такой флаг OTG_FS_GOTGCTL & OTG_GOTGCTL_BSVLD определяю подключение и отключение USB кабеля к моему девайсу Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Димон Безпарольный 2 22 сентября, 2016 Опубликовано 22 сентября, 2016 · Жалоба я проверяю вот такой флаг OTG_FS_GOTGCTL & OTG_GOTGCTL_BSVLD определяю подключение и отключение USB кабеля к моему девайсу Счастье было так близко, но ускользнуло. Значение регистра GOTGCTL = 0x20001FD0 и не меняется. Даже если я выдергиваю шнур. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
pvo125 0 23 сентября, 2016 Опубликовано 23 сентября, 2016 · Жалоба А почему такое значение в регистре OTG_GOTGCTL ?. Там ведь с 31-21 бит все зарезервировано и reset state нулевое. А у Вас единица получается в 29 бите. Возможно не тот регистр смотрите. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Timmy 1 23 сентября, 2016 Опубликовано 23 сентября, 2016 · Жалоба А почему такое значение в регистре OTG_GOTGCTL ?. Там ведь с 31-21 бит все зарезервировано и reset state нулевое. А у Вас единица получается в 29 бите. Возможно не тот регистр смотрите. Там есть недокументированные биты. И не только в этом регистре. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
pvo125 0 23 сентября, 2016 Опубликовано 23 сентября, 2016 · Жалоба Как понять недокументированы? Как раз 31-21 биты документированы и написано что зарезервированы и должны сохранять reset value. А reset value 0x0001 0000. Т е 31-21 должны быть нулевые. Откуда может взяться 1 в 29 бите в этом регистре. Или я что то не дочитал? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
esaulenka 7 23 сентября, 2016 Опубликовано 23 сентября, 2016 · Жалоба Так а где виснет-то?! Отключить ватчдог, смоделировать, остановить в отладчике - не? А vbus (оно же "отрубание шнура") чудесно видно на соотв. ноге. Просто как gpio. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Timmy 1 23 сентября, 2016 Опубликовано 23 сентября, 2016 · Жалоба Как понять недокументированы? Как раз 31-21 биты документированы и написано что зарезервированы и должны сохранять reset value. А reset value 0x0001 0000. Т е 31-21 должны быть нулевые. Откуда может взяться 1 в 29 бите в этом регистре. Или я что то не дочитал? Просто в мануале написана не совсем правда. В реальном железе 29-й бит сам поднимается в единичку(его можно программно сбросить, но Куб этого не делает). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Димон Безпарольный 2 25 сентября, 2016 Опубликовано 25 сентября, 2016 · Жалоба Там есть недокументированные биты. И не только в этом регистре. Да, 29-й бит почему - то читается как 1. Но регистр тот. Проверил. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Димон Безпарольный 2 27 сентября, 2016 Опубликовано 27 сентября, 2016 · Жалоба Отследил как мог, только это не помогло. Вываливается действительно в HardFault_IRQn. После трех циклов ожидания. Последняя выполняемая строчка while (hcdc->TxState != 0). После нее - HardFault. Что с этим делать - не знаю. uint8_t CDC_Transmit_FS(uint8_t* Buf, uint16_t Len) { uint8_t result = USBD_OK; /* USER CODE BEGIN 7 */ USBD_CDC_HandleTypeDef *hcdc = (USBD_CDC_HandleTypeDef*)hUsbDevice_0->pClassData; uint32_t tickstart = TimerTick; while (hcdc->TxState != 0) { if ((TimerTick - tickstart) > 1000) //100мс { // return 1; // } // } USBD_CDC_SetTxBuffer(hUsbDevice_0, Buf, Len); USBD_CDC_TransmitPacket(hUsbDevice_0); /* USER CODE END 7 */ return result; } Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Димон Безпарольный 2 28 сентября, 2016 Опубликовано 28 сентября, 2016 · Жалоба Нашел выход. Не очень хороший, но работает. uint8_t CDC_Transmit_FS(uint8_t* Buf, uint16_t Len) { /* USER CODE BEGIN 7 */ if(CDC_Stop) {return 2;} //Разрешение выдачи информации в CDC UART USBD_CDC_HandleTypeDef *hcdc = (USBD_CDC_HandleTypeDef*)hUsbDevice_0->pClassData; uint32_t tickstart = TimerTick; // while (hcdc->TxState != 0) // { if ((TimerTick - tickstart) > 1000) //100мс { // CDC_Stop = 1; //Разрешение выдачи информации в CDC UART return 1; // } // } USBD_CDC_SetTxBuffer(hUsbDevice_0, Buf, Len); USBD_CDC_TransmitPacket(hUsbDevice_0); /* USER CODE END 7 */ return 0; } Если ожидание готовности CDC UART принять данные превышает 1с, выставляется флаг CDC_Stop = 1, по которому данные с CDC UART больше не поступают. Но поскольку прием по CDC UART никто не отменял, этот флаг командой сбрасываетя. Можно выдернуть шнур, потом воткнуть обратно - ничего не виснет. Этот же флаг сбрасывается в функции static int8_t CDC_Init_FS(void). Она к счастью вызывается. Функция static int8_t CDC_DeInit_FS(void) не вызывается никогда. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться