Форум разработчиков электроники ELECTRONIX.ru > STM32F476 USB CDC. Device. Как отследить отключение / подключение

Димон Безпарольный

Sep 21 2016, 16:55

Проблема возникает когда контроллер что - то выдает по 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

Sep 22 2016, 06:37

Для начала можно попробовать понять что вообще происходит при отключении: hardfault, зависание на определенном участке кода или еще что-то.
Скорее всего авторами стека ситуация разрыва соединения не предусмотрена вообще.

Димон Безпарольный

Sep 22 2016, 07:56

Цитата(Wasserati @ Sep 22 2016, 09:37)

Для начала можно попробовать понять что вообще происходит при отключении: hardfault, зависание на определенном участке кода или еще что-то.
Скорее всего авторами стека ситуация разрыва соединения не предусмотрена вообще.

Не попадант он ни в одну ловушку. В hardfault тоже. Я не умудрен в отладчике - толком не знаю как посмореть где виснет.

klen

Sep 22 2016, 14:44

я проверяю вот такой флаг OTG_FS_GOTGCTL & OTG_GOTGCTL_BSVLD
определяю подключение и отключение USB кабеля к моему девайсу

Димон Безпарольный

Sep 22 2016, 15:59

Цитата(klen @ Sep 22 2016, 17:44)

я проверяю вот такой флаг OTG_FS_GOTGCTL & OTG_GOTGCTL_BSVLD
определяю подключение и отключение USB кабеля к моему девайсу

Счастье было так близко, но ускользнуло. Значение регистра GOTGCTL = 0x20001FD0 и не меняется. Даже если я выдергиваю шнур.

pvo125

Sep 23 2016, 05:06

А почему такое значение в регистре OTG_GOTGCTL ?. Там ведь с 31-21 бит все зарезервировано и reset state нулевое. А у Вас единица получается в 29 бите. Возможно не тот регистр смотрите.

Timmy

Sep 23 2016, 06:01

Цитата(pvo125 @ Sep 23 2016, 08:06)

А почему такое значение в регистре OTG_GOTGCTL ?. Там ведь с 31-21 бит все зарезервировано и reset state нулевое. А у Вас единица получается в 29 бите. Возможно не тот регистр смотрите.

Там есть недокументированные биты. И не только в этом регистре.

pvo125

Sep 23 2016, 06:24

Как понять недокументированы? Как раз 31-21 биты документированы и написано что зарезервированы и должны сохранять reset value. А reset value 0x0001 0000. Т е 31-21 должны быть нулевые. Откуда может взяться 1 в 29 бите в этом регистре. Или я что то не дочитал?

esaulenka

Sep 23 2016, 06:30

Так а где виснет-то?! Отключить ватчдог, смоделировать, остановить в отладчике - не?

А vbus (оно же "отрубание шнура") чудесно видно на соотв. ноге. Просто как gpio.

Timmy

Sep 23 2016, 09:53

Цитата(pvo125 @ Sep 23 2016, 09:24)

Как понять недокументированы? Как раз 31-21 биты документированы и написано что зарезервированы и должны сохранять reset value. А reset value 0x0001 0000. Т е 31-21 должны быть нулевые. Откуда может взяться 1 в 29 бите в этом регистре. Или я что то не дочитал?

Просто в мануале написана не совсем правда. В реальном железе 29-й бит сам поднимается в единичку(его можно программно сбросить, но Куб этого не делает).

Димон Безпарольный

Sep 25 2016, 16:53

Цитата(Timmy @ Sep 23 2016, 09:01)

Там есть недокументированные биты. И не только в этом регистре.

Да, 29-й бит почему - то читается как 1. Но регистр тот. Проверил.

Димон Безпарольный

Sep 27 2016, 19:27

Отследил как мог, только это не помогло. Вываливается действительно в 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;
}

Димон Безпарольный

Sep 28 2016, 07:39

Нашел выход. Не очень хороший, но работает.

Код

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) не вызывается никогда.