AT91SAM7S USB "залипает", время от времени, под настроение)) Опции

[overloaded]

ЮСБ девайс постоянно обменивается парой сотен байт, размер приема и передачи всегда одинаковый.
Период такого обмена выходит от 1мс. Для теста контроллер вообще ничего кроме этого не делает (программа на ПК кстати тоже=) ). Через рендомные промежутки времени (от получаса до 20 часов) передача прекращается и контроллер ждет в функции Write

Код

// Wait for the the first bank to be sent
while ( !(pUdp->UDP_CSR[AT91C_EP_IN] & AT91C_UDP_TXCOMP) );

а ПК, в свою очередь, где=то внутри функции Read(обмен синхронный). Так продолжается от 5 до 30 секунд, после чего
передача чудесным образом возобновляется. Пробовал таймауты на стороне контроллера.
Слал пакеты неправильной длинны (больше или меньше ожидаемого), все синхронизхируется и возобновляется нормально, но проблема остается.

Пробовал bulkusb.sys+basicUSB чуть доделанный, CDC+ЦДЦ пример из ЮСБ фреймворк(типа на прерываниях), симптомы одни и те же.
Что делать?

[aaarrr]

Постоянно работаю с 5.1.2600.2180 и как-то проблем не вижу. Чем наличие или отсутствие ZLP может помешать?

[overloaded]

Мне мешает тем, что: контроллер прочитал структуру - отправил структуру. Синхронно. И когда приходит ЗЛП вместо структуры непонятно что делать - еще раз читать или как и обычно писать.
Логично было бы еще раз читать, но ЗЛП (кроме просто ложного пакета) может сигнализировать и конец передачи. А в таком случае еще раз читать нельзя т.к. ПК не дождется данных.
Это не то что сильно мешает, просто напрягает то, что на разных ПК по-разному будет.

Но именно проблема ЗЛП к первому посту не относится.. Там просто нет запроса OUT от хоста.. Вот нет и все! (смотрел программным снупером, аппаратного нет).

[aaarrr]

Мне мешает тем, что: контроллер прочитал структуру - отправил структуру. Синхронно.

Вот это, по-моему, и является настоящим источником проблем.

Но именно проблема ЗЛП к первому посту не относится.. Там просто нет запроса OUT от хоста.. Вот нет и все! (смотрел программным снупером, аппаратного нет).

А с другим драйвером (не CDC) не пробовали проверить?

[overloaded]

Вот это, по-моему, и является настоящим источником проблем.

А почему? Зачем разрабатывать систему команд если нужна только одна? И скорость с системой команд думаю будет поменьше.. В чем ненадежность и проблемность? Или я не так Вас понял? Какую альтернативу посоветуете и что в ней лучше? И по-идее же доставка гарантирована, поэтому сколько посылаем столько и получаем.. Тогда чем плоха синхронная?

А с другим драйвером (не CDC) не пробовали проверить?

Пробовал bulkusb.sys из ДДК, но там сниффером не смотрел т.к. очень редко происходит, трудно поймать.. Еще буду пробовать.. Но в любом случае нужно ЦДЦ..

[aaarrr]

Зачем разрабатывать систему команд если нужна только одна?

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

[overloaded]

Ну, если действительно все так просто - одна команда и работа в режиме отравил-принял .....

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

Заметил что при считывании в виндусе пакета физически приходит-то все, но отдается иногда(редко) частями.
Т.е. может прийти 1 байт а за ним все остальные..(при размере конечной точки 64 байта и размере передачи, скажем, 40 байт) Решилось примерно так, хотя непонятные вещи таки остались..

Код

                                        
                    while (ComPortReceivedBytesCnt != ComPortReadLength)
                    {
                        if ((ComPortReadLength - ComPortReceivedBytesCnt) > 0)
                            ComPortReceivedBytesCnt += DevComPort.Read(buf, ComPortReceivedBytesCnt, ComPortReadLength - ComPortReceivedBytesCnt);
                        else
                        {
                            Form1.log_file.Write("Ошибка синхронизации: получено больше данных чем запрашивалось! Порт " + dev_guid, this.ShortName, Form1.log_pShowMsg, Form1.log_pWriteLog);
                            return RWResult.SyncError;
                        }
                        
                    }

И чтоб не плодить темы, хочу поинтересоваться насчет spurious прерывания. Никак не могу избавиться,
очень часто возникает (при некотором правильном подборе количества строчек кода в определенныъ местах)) ) - раз в пару секунд или даже чаще. Варианты и комбинации пробовал разные, не помогает.. Или такая частота возникновения - это нормально? Код:

Код

void disable_stepper_interrupt()
{
    *AT91C_TC2_CCR = AT91C_TC_CLKDIS; // Channel Control Register
    *AT91C_TC2_IDR = AT91C_TC_CPCS;
    *AT91C_AIC_IDCR = (1<<AT91C_ID_TC2);  
    *AT91C_AIC_ICCR = (1<<AT91C_ID_TC2);  // Interrupt Clear Command Register    
}

Комбинации строк пробовал почти все ) Понятно что TC_IDR и CLKDIS лишнее, но другие варианты у меня закончились, пробовал что попало)) И как попытаться (и стоит ли) сделать вызовы пореже?

[aaarrr]

И чтоб не плодить темы, хочу поинтересоваться насчет spurious прерывания.

Вообще, при работе от внутренних источников, spurious-прерывания получить достаточно трудно. С какой частотой приходят прерывания (нормальные) от таймера?

И еще:

Код

    *AT91C_AIC_ICCR = (1<<AT91C_ID_TC2);  // Interrupt Clear Command Register

Если прерывание настроено на работу по уровню, то эта строка не имеет смысла. Смысла работать с внутренними источниками по фронту тоже нет.

[overloaded]

Вообще, при работе от внутренних источников, spurious-прерывания получить достаточно трудно. С какой частотой приходят прерывания (нормальные) от таймера?

И еще:

Код

    *AT91C_AIC_ICCR = (1<<AT91C_ID_TC2);  // Interrupt Clear Command Register

Если прерывание настроено на работу по уровню, то эта строка не имеет смысла. Смысла работать с внутренними источниками по фронту тоже нет.

По уровню. Но очищается же оно при записи EOICR вроде? А здесь не пишем.. Функция же не из прерывания вызывается..

11 КГц. Вроде не так много.. Просто до этого действительно не было их почти а счас что-то куда-то магически сдвинулось и начали совпадать) Кстати, вызывает их запись TC2_IDR или AIC_IDCR, что логично. Не то чтоб они мне сильно мешали, может просто лажа в чем-то другом, а я и не подозреваю)

[aaarrr]

По уровню.

Просто запись ICCR для перываний, сконфигурированных на работу по уровню, бессмысленна. Только код засоряет.

11 КГц. Вроде не так много.. Просто до этого действительно не было их почти а счас что-то куда-то магически сдвинулось и начали совпадать) Кстати, вызывает их запись TC2_IDR или AIC_IDCR, что логично. Не то чтоб они мне сильно мешали, может просто лажа в чем-то другом, а я и не подозреваю)

Ну, если disable_stepper_interrupt() тоже вызывается достаточно часто, то ничего удивительного в возникновении spurious нет.

[overloaded]

Просто запись ICCR для перываний, сконфигурированных на работу по уровню, бессмысленна. Только код засоряет.

Да я хотел чтоб если спуриоус произойдет и флаг останется не сброщенным сбросить его чтоб при разрешении оно сразу не вызвалось. Но теперь подумал что даже лучше чтоб вызывалось)
И спасибо за консультации)