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

Z_h_e

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

Реклама

isx · Сообщение **isx** » Сб июн 04, 2016 20:27:58

Ну так если мы записываем на место значения "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 · Сообщение **isx** » Сб июн 04, 2016 20:46:01

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

Реклама

Z_h_e

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

Реклама

isx · Сообщение **isx** » Сб июн 04, 2016 21:02:55

Ошибка была в предыдущем примере. Исправил, но смысл не поменялся....\
Пример с 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.

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

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

isx · Сообщение **isx** » Вс июн 05, 2016 09:09:20

Не пойму почему, но прерывание по 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. Что Вам мешает мониторить этот регистр?

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

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

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

Да, так.

isx · Сообщение **isx** » Сб июн 11, 2016 18:30:57

Появилось маленько времени, возвращаюсь к работе с 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 · Сообщение **isx** » Вс июн 12, 2016 17:34:27

Можете объяснить, что делает эта строка? Я что-то не пойму что происходит там с адресом - к чему сдвиг на 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, а на прерывания ей плевать.
В чем может быть проблема.? Перерыл кучу информации, толку ноль. Застрял.

isx · Сообщение **isx** » Пн июн 13, 2016 16:14:22

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

Serg1987

isx писал(а):А прерывание у вас точно правильно обозвано?
В моем файле с дефайнами (на 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

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

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

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

isx · Сообщение **isx** » Пн июн 13, 2016 19:42:18

Если не ошибаюсь, то момент соединения с шиной обозначается прерыванием по РЕСЕТ.
У меня в 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 · Сообщение **isx** » Пн июн 13, 2016 20:31:39

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

Код: Выделить всё

	 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 успешное завершение передачи и только тогда разрешать прием, но не уверен, необходимо ли это?