Я кейс создал на сайте атмела, они мне ответили:
What is the firmware version your using now.? Please try with 18.1 firmware version available in ASF 3.23.1 if your not using updated.

ASF 3.23.1 я скачал, установил, а где брать 18.1 firmware не пойму, в атмел студио 18.0.0 предлагается.

Жаль в кейсе про 12-15сек ничего не написал.

Это может быть баг с нумерацией, думаю стоит попробовать его накатить. У меня на рабочем компе есть это обновление, но сегодня выходной.


Обратите внимание, что при обновлении нужно обязательно обновить и файлы на хосте, они опять протокол сломали.

Ну и скорее всего это не поможет.

Описание проблемы ушло разработчикам.

Для обновления ПО нужно создать проект из примера WINC1500_FIRMWARE_UPDATE_AND_DOCUMENTATION. Но я тоже вижу только v18.0.3.

v18.1 существует, но видимо пока не опубликована.


Как выяснилось, v18.0.3 - это ошибка, на самом деле версия в последнем ASF v18.1.

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

Обновил прошивку и драйвер. Не помогло. Точно также через 12 сек падает. Пробовал уменьшать размер пачки данных, передаваемых по udp (300байт сделал, а было 970), и вводить паузу после отправки udp пакета - падает не через 12 сек, а через 40 сек.

В файлах драйвера не увидел значимых изменений. В основном лишние пробелы и табы поудаляли.

Спасибо, что передали разработчикам описание проблему. Может это и принесет результат.

Их ответ стандартный - нужно воспроизводить на D21. Я понимаю, что это абсурд и мы не можем заставить каждого клиента покупать D21 Xpro просто чтобы багрепорты слать. Это со временем продет.

Если используется плата расширения XPro, то в зависимости от версии платы на ней либо есть разъем DEBUG UART или FTDI c USB. Нужно получить лог с этого разъема в момент падения.

И еще, что именно было изменено при порте на Microblaze?


А так же продолжайте теребить официальный саппорт. И номер кейса мне отправьте пожалуйста.

Сообщение отредактировал ataradov - May 28 2015, 15:30

SAMD21 имеется, и разъем у него DEBUG microUSB (ну наверно там FTDI c USB). А как получить лог с этого разъема в момент падения?

При портировании под Nios (софт процессор Altera) заменил в nm_bus_wrapper_samd21.c в функции nm_bus_ioctl обращение к функции spi_rw на обращение к альтеровской функции - чтение/запись по spi. Прерывание от wnc посадил на стандартный обработчик Nios, в нем вызываю isr() - ту функцию, что вызывается у атмела. Вот в принципе и все.

Номер кейса 00017827.

Разъем должен быть на самой плате расширения с модулем WINC1500. Существует 2 версии - первая с разъемом micro-USB, вторя - без, но 3 контактами под UART (скорее всего у вас такая). На ней есть отверстия для пайки помеченные как DEBUG UART (RX, TX, GND). Модуль постоянно валит отладочную информацию в этот порт. Достаточно подключить USB-to-UART адаптер и настроить COM-порт на 115200 8N1.

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

Снял лог с DEBUG UART,ничего интересного в нем нет, на TCP соединения две записи складываются, на UDP вообще никакой информации не добавляется. В момент падения, постоянного дма аддр =0, тоже ничего не выводится в лог.


Решил все таки проверить на SAMD21 как udp себя ведет. Открыл проект с примером от Атмел udp example. Там 10 удп засылок, сделал бесконечный цикл. Еще там пауза между засылками была, убрал ее. Вообщем точно также выскакивает дма аддр = 0.
Подконнектился к домашнему вифи роутеру Netgear jwr2000. Сначала вроде ничего, полет нормальный, иногда дма аддр проскакивали. Потом увеличил размер удп засылок, было байт 15, сделал 1400. Стало и на этом роутере отваливаться.

Если раньше у меня еще были сомнения, вдруг это я чего нахимичил в плис, spi не так дергаю, в коде атмела чего поломал, то теперь сомнений нет - косяк в их модуле, в их коде!

У меня и раньше сомнений не было . Проблема убедить, но я над этим работаю. Они просто еще ни одного продута, который идет широкой публике не выпускали, так что они пока не знают, что такие проблемы им придется решать, а не отбрыкиваться тем, что покупаете мало. А кто будет покупать много, если оно не работает?

То-есть пример на D21 работает с Android 4.0 как нужно, а на Android 2.3 и Netgear jwr2000 - нет?

PS: я подписался на ваш кейс, но активно вмешиваться не буду. Я хочу посмотреть как официальный суппорт это разрулит.

D21 с андроид 4 почти сразу падает, с netgear с маленькими пакетами работало, с большими пакетами - упало. С андроидом 2.3, с которым у меня плиска нормально работает, забыл проверить(

Несовместимость с одним устройством - я еще могу понять, но несколько сразу - это очень странно.

Единственная разница, которую я вижу - это настройки страны в AP. Правда не знаю на что именно они влияют, скорее всего только на мощность. Не думаю, что их можно изменить в телефоне, но у Netgear точно настройка должна быть. Можно попробовать с ней поиграться.

Пришлите проект для D21, я попробую тут воспроизвести.

У товарища ASUS PADFON, также дма аддр = 0,отваливается.


Вот проект для D21. Тот, с которым работал, дома, этот на память восстановил, может и ошибки будут. Основа - пример из атмел студио, с обновлениями до 18.1.1.
Я внес изменения в main_samd21.c:
- убрал ограничение в 10 удп пакетов,
- убрал паузу между засылкой пакетов,
- увеличил размер засылаемого удп сообщения (buff[1400])

Еще в ASF/common/components/WiFi/winc1500/driver/source/m2m_hif.c в функции hif_send добавил принтф, если дма аддр = 0.
 WINC1500_SIMPLE_UDP_EXAMPLE_18.1.1_____me.zip ( 2.25 мегабайт ) Кол-во скачиваний: 73

строчка из hif_send:


Вот читаем мы из winc регистр 0x150400, тем самым узнаем дма аддр, а может можно прочитать еще какой регистр и узнать сколько места есть в буфере, ведь по сути просто где то заканчивается место?

Все эти регистры не документированы и о них знать не положено. Все должно работать с предоставленным API. Это по-идее, конечно. Я пытаюсь сделать так, чтобы интерфейс был документирован и не менялся, но пока без особых успехов.

Я позже сегодня попробую погонять новую прошивку. Но у меня есть подозрение, что 1400 байт может быть слишком много. Хотя я пробовал слать звук чрез 1024-байтные пакеты и все работало.

Ну и 0 - это индикация, что пока что нет места. Это нормально при плотном потоке. А вот то, что оно зависает так на долго - это не нормально.