STM32 и USB (практика)

[Z_h_e]

Togle это инвертирование при записи лог.1.

[isx]

Ну так если мы записываем на место значения "0х00" значение "0х10", то и при тугле итоговое значение будет тоже "0х10". Или я опять что-то не догоняю?

[Z_h_e]

USB->EP0R = USB->EP0R | USB_EP_TX_NAK;
USB->EP0R = USB->EP0R | USB_EP_RX_VALID;

Так понятнее что у Вас происходит?

[isx]

Все равно не понятно....
Вот к примеру, USB->EP0R = 0b0000000000000000 (по умолчанию). USB_EP_TX_NAK = 0x0020 = 100000. Переключится в итоге пятый бит, а это первый бит STAT_TX. В итоге получается значение STAT_TX = 10 - что соответствует NAK.

Последний раз редактировалось isx Сб июн 04, 2016 20:59:50, всего редактировалось 1 раз.

[Z_h_e]

А теперь тоже самую логику подключите к USB->EP0R = USB->EP0R | USB_EP_RX_VALID;

[isx]

Ошибка была в предыдущем примере. Исправил, но смысл не поменялся....\
Пример с USB->EP0R = USB->EP0R | USB_EP_RX_VALID.
USB_EP_RX_VALID = 0х3000 = 0b0011000000000000. Так и получается значение VALID в RX

[Radist_M]

Когда происходит событие по приему или передаче - срабатывает прерывание. Значения полей STAT_TX и STAT_RX автоматически (железом USB) устанавливаются в NAK (10). теперь пока софт МК будет думать что делать дальше хост будет получать на запросы IN/OUT - NAK. Тут есть время поглядеть принятый пакет и решить что делать дальше.

Далее.
USB_EP_RX_VALID - Поле STAT_RX = 11.

А у нас STAT_RX по результату приема SETUP пакета в состоянии NAK (10). Если выполнить инструкцию USB->EP0R = USB->EP0R | USB_EP_RX_VALID., то NAK (10) изменится на (01).

10^11 = 01.

Ошибка была в предыдущем примере. Исправил, но смысл не поменялся....\
Пример с USB->EP0R = USB->EP0R | USB_EP_RX_VALID.
USB_EP_RX_VALID = 0х3000 = 0b0011000000000000. Так и получается значение VALID в RX

Да, забыл. Тут все верно. Если речь идет про состояние после резета, то регистр девственно чист. 0 и все. Вот тут-то мы записывая 11 и получим 11.

[isx]

Не пойму почему, но прерывание по CTR происходит только если выставлять ИМЕННО в таком порядке:

Код:

USB->EP0R   |= USB_EP_TX_NAK; // Готовы к передаче, но данных для передачи нет
  USB->EP0R   |= USB_EP_RX_VALID; // К приему готов   


Если поменять местами, то ничего не происходит...
И еще, может кому поможет, так как я не знал. Для того, чтобы произошло прерывание пользовательский разъем USB нужно ПОДКЛЮЧАТЬ при ЗАПУЩЕННОЙ отладке. Если разъем будет подсоединен до запуска отладки, то прерывание CTR не произойдет до тех пор, пока мы заново не переткнем пользовательский разъем.
Пока разбираюсь с отправкой дескриптора нужно выяснить один момент. Подскажите пожалуйста, как отправить пакет нулевой длины? Нужно USB_COUNT0TX выставить в ноль и USB_EP_TX в VALID. Тогда если хост просит ответить восьмью байтами то нужно USB_COUNT0TX сделать в 8 байт?

[Z_h_e]

Если бы Вы читали то что я Вам пишу, то вчера разобрались бы еще. Третий раз говорю, выполните по шагам эти строчки и поглядите как меняется регистр EP0R. Что Вам мешает мониторить этот регистр?

Для того, чтобы произошло прерывание пользовательский разъем USB нужно ПОДКЛЮЧАТЬ при ЗАПУЩЕННОЙ отладке.

Почитайте про запросы USB, я Вам тоже об этом писал. Вы задали банальный вопрос, говорящий о том что нет совсем представления как работает USB.

Подскажите пожалуйста, как отправить пакет нулевой длины? Нужно USB_COUNT0TX выставить в ноль и USB_EP_TX в VALID. Тогда если хост просит ответить восьмью байтами то нужно USB_COUNT0TX сделать в 8 байт?

Да, так.

[isx]

Появилось маленько времени, возвращаюсь к работе с USB .
Остановился на том, что хост отправляет запрос дескриптора. Начал записывать массив дескриптора (стырил с какого-то сайта) в память, и опять грабли .
Сделал так:

Код:

if (USB->ISTR & USB_ISTR_CTR)
{
   USB->CNTR &= ~USB_EP_CTR_RX;

   switch    (*(__IO uint32_t*)(0x400060C1))
   {
      case 0x6:
        for (i = 0; i < 17; i++)
          {
          *(__IO uint32_t*)(0x40006000 + i) = Virtual_Com_Port_DeviceDescriptor[i];
          }
            break;
   }
}   

Как я понял, когда i станет равным 2, то дескриптор начнет писаться в недоступную область, и дальше все полетит к чертям. Как это можно грамотно обойти? Я вижу только один способ - ввести отдельную переменную с инкрементацией в каждом проходе цикла и переменную с текущим смещением. Как только инкрементируемая переменная становиться равной 2, то к переменной смещения прибавляем двойку, и т.д. Но мне кажется, что это как-то "топорно"
Но основная проблема появилась еще раньше. Первым записывается нулевой элемент массива. Запись проходит нормально, но когда я пишу следующий элемент, то значение по адресу нулевого элемента затирается в 0х00. Почему так происходит?

[Z_h_e]

Я вот так заполняю буфер.

Спойлер

Код:

//Функция заполнения буфера отправки
void Buffer_Fill_Tx (uint8_t NumEP, uint8_t *Desc,uint8_t Len){   //NumEP -номер точки, Desc - массив байтов для отрпавки. Len - длина массива

   uint16_t *pCount, *pTXBuf;
   uint8_t i;

   pTXBuf=0x40006000+NumEP*0x10; //адрес начало буфера TX
   pCount=0x40006004+NumEP*0x10; //адрес COUNTn_TX

   pTXBuf=*pTXBuf*2+0x40006000;

   *pCount=Len;//длина пакета
   for (i=0;i<Len;i+=2) pTXBuf[i]=Desc[i]+(Desc[i+1]<<8); //заполним буфер данными

}

Запросов будет много разных и анализировать его надо весь, а не только поле bRequest

Спойлер

Код:

switch ((ConfigPacket.bmRequestType << 8 ) | (ConfigPacket.bRequest)) {

                        case 0x8006:{//ЗАПРОС ДЕСКРИПТОРА
                                               //выбор типа дискриптора
                                           switch(ConfigPacket.wValue) {
                                           case 0x0100:{//Запрос дескриптора устройства
                                                                                 
                                               Buffer_Fill_Tx (0,Device_Descriptor,18); //заполнение  буфера отправки
                                               Set_Status_EPR(0,Valid,TX); // отправим дескриптор устройста,
                                               break;}

                                           case 0x0200:
                                                             ...
                                                             ...
                                                             ...

[isx]

Можете объяснить, что делает эта строка? Я что-то не пойму что происходит там с адресом - к чему сдвиг на 8?

Код:

pTXBuf[i]=Desc[i]+(Desc[i+1]<<8)

[Z_h_e]

uint16_t *pTXBuf
uint8_t *Desc

[Serg1987]

Попалась полезная ветка по USB. Есть вопросы. Возникли проблемы ещё на этапе инициализации.

-Сначала инициализируется модуль USB. просто вкючаете, подкючаете генератор и т.д.
- По событию SE0 (воткнули девайс в комп) инициализируете нужные регистры, это событие кстати сбросит их в начальное состояние само.
-Затем устанавливаете в регистре EP0 VALID RX, т.е. МК готов принять данные для нулевой точки.
-Возникает прерывание об успешной транзакции. Расшифровываете и понимаете что что то получили.
- читаете что лежит в буфере приема, там будет запрос дескриптора устройства.
-ложите в буфер отправки дескриптор устройства и выставляете в регистре EP0 VALID TX и контроллер сам все отправит.
-после события об успешной отправки опять переводите МК в состояние в готов принять.

Который день пытаюсь реализовать прерывание по событию присоединения к шине USB (то, что вы Z_h_e идентифицируете как событие SE0)
Пишу в Кокосе. Контроллер stm32f103rbt6. Инициализирую систему тактирования, USB, но прерываний почему-то не происходит. Даже по событию превышения ожидания (SUSP), хотя отладчик показывает, что соответствующие флаги в реге ISTR успешно выставляются. Я уже все мозги сломал, в чем может быть дело.
Сразу инициализирую систему от внешнего кварца 8МГЦ. Умножитель PLL = x6

Код:

int main(void)
{
    __enable_irq ();
//*****Настройка тактирования
   //сброс системы тактирования
   RCC_DeInit();

   //Включаем HSE
   RCC->CR |= RCC_CR_HSEON;
   //Ждем готовности HSE
   while((RCC->CR & RCC_CR_HSERDY) == 0) {}
   //Предделитель AHB
   RCC->CFGR |= RCC_CFGR_HPRE_0;
   //Очистка регистра умножителя PLL
   RCC->CFGR &= ~RCC_CFGR_PLLMULL;
   //источник PLL от внешнего кварца
   RCC->CFGR |= RCC_CFGR_PLLSRC_HSE;
   //умножитель PLL x6
   RCC->CFGR |= RCC_CFGR_PLLMULL6;
   //Включаем PLL
   RCC->CR |= RCC_CR_PLLON;
   //Ждем готовности PLL
   while((RCC->CR & RCC_CR_PLLRDY) == 0) {}
   //очистка регистра  SW
   RCC->CFGR &= ~RCC_CFGR_SW;
   //выбор источника тактирования PLL
   RCC->CFGR |= RCC_CFGR_SW_1;
   //Ожидание включения PLL
   while((RCC->CFGR & RCC_CFGR_SWS) != RCC_CFGR_SWS_1) {}
//*********************************************************
//Включим тактирование - порт A, B,C и альтернативного режима
   RCC->APB2ENR |= RCC_APB2ENR_IOPBEN | RCC_APB2ENR_IOPAEN | RCC_APB2ENR_IOPCEN|RCC_APB2ENR_AFIOEN;
// НОЖКА C9
    GPIOC->CRH &= ~GPIO_CRH_CNF12_0 & ~GPIO_CRH_CNF12_1;
    GPIOC->CRH |=  GPIO_CRH_MODE12;
    GPIOC->ODR |= GPIO_ODR_ODR12;



Затем инициализирую USB:

Код:

   //делитель USB равен 1
   RCC->CFGR |= RCC_CFGR_USBPRE;
   //Разрешаем USB
   RCC->APB1ENR |= RCC_APB1ENR_USBEN;

//Очистка флагов USB
   USB->ISTR = 0;
   USB->CNTR = 0;

   //Разрешаем прерывания
   NVIC_EnableIRQ(USB_LP_CAN1_RX0_IRQn);
   NVIC_SetPriority (USB_LP_CAN1_RX0_IRQn, 2);
    NVIC_EnableIRQ(USBWakeUp_IRQn);

       //настройка прерываний от перефирии
    EXTI->RTSR |= EXTI_RTSR_TR18; // прерывание №18
    EXTI->IMR |= EXTI_IMR_MR18; // прерывание по выводам
    EXTI->EMR |= EXTI_EMR_MR18; // прерывание по WU

    USB->CNTR &= ~USB_CNTR_PDWN; //подаем питание
    USB->CNTR &= ~USB_CNTR_FRES; //Включаем тактирование

//Настройка прерываний
   USB->CNTR |= USB_CNTR_CTRM;
     USB->CNTR |= USB_CNTR_WKUPM; 
   USB->CNTR |= USB_CNTR_SUSPM;
   USB->CNTR |= USB_CNTR_RESETM; 


Функцию прерывания реализую так:

Код:

void USB_LP_IRQHandler(void)
{
      //Ждем события
   if ((USB->ISTR & USB_ISTR_SUSP))
       {
      //какой-то код
       }
}

Итог, программа выставляет флаги и успешно уходит в цикл while, а на прерывания ей плевать.
В чем может быть проблема.? Перерыл кучу информации, толку ноль. Застрял.

Вложения

Codusb.txt

Код в полном виде

(2.5 KiB) Скачиваний: 170

[isx]

А прерывание у вас точно правильно обозвано?
В моем файле с дефайнами (на stm32f1x) оно определено как USB_LP_CAN1_RX0_IRQn. Тогда и прерывание следовало бы обозвать как void USB_LP_CAN1_RX0_IRQnHandler(void)....

[Serg1987]

А прерывание у вас точно правильно обозвано?
В моем файле с дефайнами (на stm32f1x) оно определено как USB_LP_CAN1_RX0_IRQn. Тогда и прерывание следовало бы обозвать как void USB_LP_CAN1_RX0_IRQnHandler(void)....

Спасибо! Я уже сам дошел до этого. На прерывания отзывается. Код немного подправил. Теперь первый РЕСЕТ (по сбросу FRES) игнорируется. Он мне без надобности (пока так). Регистр CNTR настраиваю отдельно. Далее теоретически следует определить момент присоединения девайса к шине хоста. Как это определить.?
Тут я не могу до конца разобраться, что делать с подтяжкой на D+. Это по поводу события соединения с шиной.
Пробовал добавить внешний pull_up резистор. Не помогает.
Во всех примерах встречалось о том, что выставляется специальный бит - USB_UP. На STM32F103 ничего такого и в помине нет. Подозреваю, что копать нужно непосредственно в настройке ног самого STM?

[Z_h_e]

Схема с резисторами.

Далее теоретически следует определить момент присоединения девайса к шине хоста. Как это определить.?

Это определит хаб, увидев что одна из линий данных "подтянулась" (воткнули разъем). Скажет об этом хосту, хост пошлет сброс. Это и есть момент подключения.

[isx]

Если не ошибаюсь, то момент соединения с шиной обозначается прерыванием по РЕСЕТ.
У меня в STM32F303 тоже нет бита подтяжки. На плате резистор тупо припаян.

А теперь вопрос к Z_h_e от меня .
Настроил по Вашему образцу отправку первого запроса дескриптора, но процесс не продвигается - при пошаговой отладке в цикле видно, что запись в память происходит, но при записи последующего значения, предыдущее стирается в ноль. Может пошаговая отладка в таких процедурах неадекватно работает? Ничего не понимаю

Код:

   
switch    (*(__IO uint32_t*)(0x400060C1))
    {
      case 0x6:
         
           for (i = 0; i < 16; i+=2)
        {
           TXBuff = Virtual_Com_Port_DeviceDescriptor[i] + (Virtual_Com_Port_DeviceDescriptor[i+1] << 8);   
        *(__IO uint32_t*)(0x40006080 + i) = TXBuff;
        }
        USB->EP0R   |= USB_EP_TX_VALID;
         break;
     }


И не могли бы Вы скинуть кусок кода с обработкой прерываний по CTR. На фоне предыдущей проблемы я не могу правильно настроить с ним работу...

[Z_h_e]

Все по одним и тем же граблям ходите.
*(__IO uint16_t*)(0x40006080 + i) = TXBuff;

Код:

USB->EP0R   |= USB_EP_TX_VALID;

После этой команды установите точку останова и проверьте значение регистра, может тут еще подвох быть. Только в момент останова выдерните разъем, а то хост не дождавшись ответа пошлет сброс и регистр обнулится. Ну или сохраните его значение в какой-нибудь переменной.

----------
Вот еще что. Не вижу где Вы указываете длину отправляемых данных и вроде длина дескрипотора устройства 18 байт, а не 16?

[isx]

Не заметил Ваше добавление. Исправил, теперь заполняется нормально:

Код:

    switch    (*(__IO uint32_t*)(0x400060C1))
    {
      case 0x6:
         
           for (i = 0; i < 18; i+=2)
        {
           TXBuff = Virtual_Com_Port_DeviceDescriptor[i] + (Virtual_Com_Port_DeviceDescriptor[i+1] << 8);   
        *(__IO uint16_t*)(0x40006080 + i*2) = TXBuff;
        }
         *(__IO uint32_t*)(0x40006004) = 0x0012;
        USB->EP0R   |= USB_EP_TX_VALID;
         test1 = USB->EP0R   |= USB_EP_TX_VALID;
         USB->EP0R   |= USB_EP_RX_VALID;
         break;
     }


Ставлю точку останова на break, значение test1 в это время 0x00000A30. Высчитал, вроде это соответствует TX_VALID. Только вот следующий запрос не приходит. Есть вариант, что нужно отследить по USB->EP0R & USB_EP_CTR_TX успешное завершение передачи и только тогда разрешать прием, но не уверен, необходимо ли это?