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

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

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

Скорее всего авторами стека ситуация разрыва соединения не предусмотрена вообще.

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

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

Скорее всего авторами стека ситуация разрыва соединения не предусмотрена вообще.

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

[klen 1]

я проверяю вот такой флаг OTG_FS_GOTGCTL & OTG_GOTGCTL_BSVLD

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

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

я проверяю вот такой флаг OTG_FS_GOTGCTL & OTG_GOTGCTL_BSVLD

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

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

[pvo125 0]

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

[Timmy 1]

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

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

[pvo125 0]

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

 

[esaulenka 5]

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

 

 

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

[Timmy 1]

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

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

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

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

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

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

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

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

 

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