[Immortal_Buka 0]

Может подскажет кто:

В соответствии с вот этой штукой: http://blogs.msdn.com/b/usbcoreblog/archiv...e-a-device.aspx

дохожу до п.6, отправляю дескриптор, и хост меня ресетит. Вероятно туплю с фазой статуса контрольной передачи.

STM32F429

Вопрос - мы получаем от хоста токен OUT и нулевой пакет данных. Чтобы ответить мы должны сделать так:

 

DIEPTSIZ0 |= 0x00080000;

DIEPCTL0 |= (USB_OTG_DIEPCTL_CNAK|USB_OTG_DIEPCTL_EPENA);

 

Или нет?

Или где в RM прочитать?

[prottoss 0]

Доброго времени суток.

Тоже решил освоить STM32 OTG_FS в качестве Device. Тоже не нравится библиотека от ST и решил написать свой драйвер. Тоже проблема с отправкой пакетов. Прочитал всю тему. Все исправил. Но хост так и не получает отравляемые данные в ходе энумерации.

 

Стратегия у меня такая:

1. В прерывании OTG_FS_GINTSTS_RXFLVL читаю регистр OTG_FS_GRXSTSP.

2. Жду прерывание от OUT Точки. Если прерывание от точки 0, и есть флаг OTG_FS_DOEPINTx_STUP вычитываю данные из RX FIFO и обрабатываю SETUP пакет от хоста.

3. Разрешаю прерывание OTG_FS_DIEPINTx_TXFE - IN FIFO путст.

4. В прерывании от IN точки по OTG_FS_DIEPINTx_TXFE отправляю данные хосту.

 

Данные вроде отправляются, судя по количеству прерываний (п. 4) но хост ресетит девай после отправки двух пакетов и далее все по новой.

Еще наблюдаю не систематическое возникновение прерываний по OTG_FS_GINTSTS_RXFLVL.

 

Вопрос - нужно ли, в обработчике OTG_FS_GINTSTS_RXFLVL вычитывать данные (что я не делаю)сразу или можно дожидаться прихода прерывания от OUT точки с флагом OTG_FS_DOEPINTx_STUP?

 

Спасибо.

 

[aaarrr 63]

Данные вроде отправляются, судя по количеству прерываний (п. 4) но хост ресетит девай после отправки двух пакетов и далее все по новой.

Хост сначала запрашивает 8 байт дескриптора устройства, поэтому фраза "количество прерываний" несколько настораживает. Можете рассказать подробнее, что и в какой последовательности происходит?

 

Вопрос - нужно ли, в обработчике OTG_FS_GINTSTS_RXFLVL вычитывать данные (что я не делаю)сразу или можно дожидаться прихода прерывания от OUT точки с флагом OTG_FS_DOEPINTx_STUP?

Я ориентировался по полю PKTSTS регистра OTG_FS_GRXSTSP - чтение по "SETUP data packet received", обработка по "SETUP transaction completed".

[prottoss 0]

Хост сначала запрашивает 8 байт дескриптора устройства, поэтому фраза "количество прерываний" несколько настораживает. Можете рассказать подробнее, что и в какой последовательности происходит?

Не совсем так по поводу запроса дескриптора устройства. Хост не может запрашивать 8 байт. Он запрашивает намного больше. Но после отправки первых 8 байт (для Windows) должен сделать USB Reset. За тем, по новой, запрос дескриптора устройства, если все в порядке, установка адреса и за тем уже все прочее.

 

У меня вот такой порядок прерываний (флаги OTG_FS):

1. OTG_FS_GINTSTS_USBRST /* USB device bus reset */

2. OTG_FS_GINTSTS_ENUMDNE /* Enumeration done */

3. OTG_FS_GINTSTS_RXFLVL /* Receive FIFO non-empty */

4. OTG_FS_GINTSTS_RXFLVL /* Receive FIFO non-empty */

5. OTG_FS_GINTSTS_USBRST /* USB device bus reset */

6. OTG_FS_GINTSTS_RXFLVL /* Receive FIFO non-empty */

7. OTG_FS_GINTSTS_RXFLVL /* Receive FIFO non-empty */

8. OTG_FS_GINTSTS_OEPINT /* EP OUT event */

8.1. OTG_FS_DOEPINTx_STUP/* Setup Phase Done (control EPs) */ - Здесь обрабатывам запрос и разрешаем прерывание TX FIFO empty */

9. OTG_FS_GINTSTS_RXFLVL /* Receive FIFO non-empty */

10. OTG_FS_GINTSTS_IEPINT /* EP IN event */

10.1 OTG_FS_DIEPINTx_TXFE /* IN endpoint FIFO empty */ - Здесь отправляем данные хосту - дескриптор устройтсва, первые 8 байт */

11. OTG_FS_GINTSTS_RXFLVL /* Receive FIFO non-empty */ - Не понял че такое???

10. OTG_FS_GINTSTS_IEPINT /* EP IN event */ -ага! данные улетели. Наверное...

12. OTG_FS_GINTSTS_OEPINT /* EP OUT event */ - вы че творите???

12.1. 8.1. OTG_FS_DOEPINTx_STUP/* Setup Phase Done (control EPs) */ - Это че за запрос??? В поле bRequest = 0 */

 

Потом куча прерываний OTG_FS_GINTSTS_RXFLVL.

Потом сброс шины.

Потом все по новой

 

 

 

 

 

Отредактировал

 

В каждом прерывании нужный флаг закрывается - пишется единица в соответствующий бит/регистр

[aaarrr 63]

Хост не может запрашивать 8 байт.

Как это не может? Может, запрашивает, и сбасывает шину при попытке передать больше, например.

 

У меня вот такой порядок прерываний (флаги OTG_FS):

Подозрительно уже начиная с п.5, какой промежуток времени проходит между пп.4-5?

[prottoss 0]

Как это не может? Может, запрашивает, и сбасывает шину при попытке передать больше, например.

Не может запрашивать меньше байт чем размер Device Descriptor. Обычно запрашивает 256 байт. Но после приема первой посылки отрубает. Т.е. отправил первые 8 байт (если ЕР0 размер равен 8 байт). Получаешь событие, что отправлены 8 байт. Далее приходит BusReset.

 

Подозрительно уже начиная с п.5, какой промежуток времени проходит между пп.4-5?

Да. Подозрительно.

1. OTG_FS_GINTSTS_USBRST /* USB device bus reset */ time = 559

2. OTG_FS_GINTSTS_ENUMDNE /* Enumeration done */ time = 569

3. OTG_FS_GINTSTS_RXFLVL /* Receive FIFO non-empty */ time = 596

4. OTG_FS_GINTSTS_RXFLVL /* Receive FIFO non-empty */ time = 596

5. OTG_FS_GINTSTS_USBRST /* USB device bus reset */ time = 6564

 

Время в миллисекундах от старта МК.

 

Вопрос мой такой - я должен вычитывать OUT FIFO сразу при приходе OTG_FS_GINTSTS_RXFLVL?

Моя программа при приходе этого прерывания просто считывает вершину OTG_FS_GRXSTSP. Ждет прерывание SETUP и там уже обрабатывает пакет. Но после обработки и отправки ответа начинается какая то каша... ПРи том что OTG_FS_GINTSTS_RXFLVL сыплется постоянно хотя я квитирую это прерывание.

[aaarrr 63]

Не может запрашивать меньше байт чем размер Device Descriptor.

Может.

 

4. OTG_FS_GINTSTS_RXFLVL /* Receive FIFO non-empty */ time = 596

5. OTG_FS_GINTSTS_USBRST /* USB device bus reset */ time = 6564

Тут хост явно чего-то безуспешно ждет. Странно только, что так долго.

 

Вопрос мой такой - я должен вычитывать OUT FIFO сразу при приходе OTG_FS_GINTSTS_RXFLVL?

Моя программа при приходе этого прерывания просто считывает вершину OTG_FS_GRXSTSP. Ждет прерывание SETUP и там уже обрабатывает пакет.

Выше уже ответил.

[prottoss 0]

А OTG_FS_GINTSTS_RXFLVL, как я понял из даташита, не квитируется? Или квитируется... В документации так много путаницы.

[aaarrr 63]

А OTG_FS_GINTSTS_RXFLVL, как я понял из даташита, не квитируется? Или квитируется... В документации так много путаницы.

Нет, нужно просто прочитать OTG_FS_GRXSTSP.

[prottoss 0]

Нет, нужно просто прочитать OTG_FS_GRXSTSP.

 

хм... ну я так и делаю - толку нет. Происходит то что сказал выше.

 

1.Читаю GRXSTSP.

2. Жду STUP от OUT EP.

3.Разрешаю IN FIFIO empty.

4. по приходу п.3 отправляю данные.

[aaarrr 63]

1.Читаю GRXSTSP.

2. Жду STUP от OUT EP.

1. Что в PKTSTS?

2. Не ждите STUP, ориентируйтесь на PKTSTS.

[prottoss 0]

1. Что в PKTSTS?

2. Не ждите STUP, ориентируйтесь на PKTSTS.

 

Зачем тогда вообще нужен бит STUP в регистре OTG_FS_DOEPINT0???

 

[aaarrr 63]

Зачем тогда вообще нужен бит STUP в регистре OTG_FS_DOEPINT0???

Не знаю, но факт в том, что точно можно обойтись без него.

[prottoss 0]

Не знаю, но факт в том, что точно можно обойтись без него.

 

Интересно:

 

Bits 20:17PKTSTS:Packet status

Indicates the status of the received packet

0001: Global OUT NAK (triggers an interrupt)

0010: OUT data packet received

0011: OUT transfer completed (triggers an interrupt)

0100: SETUP transaction completed (triggers an interrupt)

0110: SETUP data packet received

Others: Reserved

 

А что тогда означает фраза "triggers an interrupt"?

 

[aaarrr 63]

А что тогда означает фраза "triggers an interrupt"?

Загадка.

 

0100: SETUP transaction completed (triggers an interrupt)

0110: SETUP data packet received

Оба статуса вызывают прерывание.