[maxx2 0]

_4afc_, подскажите в чём основное отличие между E70 и S70?

 

 

[skripach 5]

Спасибо!

[_4afc_ 24]

не работают примеры USB из ASF332, а ещё в ASF331 они рабочие

Всё дело в файле compiler.h там какой-то чудак улучшил clz(u) и в итоге в USB всё неправильно настраивалось...

//#define clz(u)              ((u) ? __builtin_ctz(u) : 32)    //BAD from 332
  #define clz(u)              __builtin_clz(u)                     //Good from 331

После замены этой строки, примеры USB из ASF332 тоже заработали!

 

Рано я радовался. Мой код написанный под ASF не работает на HiSpeed.

 

Ситуация не очень понятная:

 

Есть две платы

 

1 с резонатором с измеренной частотой 11.9465 производящим UPLLCK = 477.858MHz

2 с генератором с измеренной частотой 11.9999 производящего UPLLCK = 479.998MHz

 

на плате с генератором работает мой код ASF и AtmelStart в режиме HS

на плате с резонатором работает только AtmelStart в режиме HS.

 

в режиме FS работает любой код на любой плате.

Причем плата с резонатором в режиме ASF HS определяется системой, но при чтении секторов правильо успевает считать только около 200 байт.

Код на AtmelStart ведёт себя похожим образом, если при конфигурации PLLA не установить ONE (MCK=24MHz).

 

Сложность в том, что весь проект написан под ASF и встроить туда кусок из AtmelStart тяжело... и на плате нет ни места под генератор, ни тока питания.

Скопировал инициализацию (MCK=150MHz) из AtmelStart в ASF - непомогло.

 

Не могу понять: допустим проблема аппаратная, но код из AtmelStart её обходит как-то. :crying:

 

 

[Шаманъ 0]

Не могу понять: допустим проблема аппаратная, но код из AtmelStart её обходит как-то. :crying:

Я в соседней ветке с подобным страдал несколько дней назад. И там описан вариант когда аппаратная проблема с КГ могла быть частично решена программно. Так что это вполне нормально. Отклонение частоты у Вашего резонатора, как по мне сильно большое. И это еще так сказать "на столе", а что будет когда температура поплывет?

Изменено 28 марта, 2017 пользователем Шаманъ

[_4afc_ 24]

Я в соседней ветке с подобным страдал несколько дней назад. И там описан вариант когда аппаратная проблема с КГ могла быть частично решена программно.

 

Не увидел решения даже частичного, где?

 

Нашел интересную ссылку, но воспользоваться не получилось - не соединяется.

 

USB / ASF - critical bug in udp_device.c

I have found a critical bug in the USB stack.

1) In some code paths the system does not disable the USB interrupts before calling udd_ep_finish_job(). This seems like an obvious bug, as there is no need to have interrupts enabled if there is no transaction queued. This alone does not cause problem however.

 

2) If someone then calls udd_ep_run(), then a race condition arises. After updating the "busy" bit, there is a period where the interrupt is not disabled. In this period, if an interrupt (on e.g. an ISO endpoint) arrives, a transaction using the old parameters in "ptr_job" will start. This is a serious bug that then leads to incorrect transfers.

 

At high speeds (lots of ISO packets) this bug is very easy to reproduce.

 

I have attached a patched version that fixes both problems.

I have marked all the changes with "DT_FIX".

 

Интересно, что в AtmelStart вроде вообще не выключают прерывания на ходу.

 

[Шаманъ 0]

Не увидел решения даже частичного, где?

Читали невнимательно. Если все время посылать на хост ZLP (когда реальных данных нет), то даже с кривым клоком хосту удается поддерживать синхронизацию. Если делать как в стандарте, то кривой клок сразу губит соединение. Что в принципе объяснимо, правда это когда уже знаешь :)

 

P.S. Это не про то, как надо делать, а про то, как бывает.

Изменено 29 марта, 2017 пользователем Шаманъ

[_4afc_ 24]

Читали невнимательно. Если все время посылать на хост ZLP (когда реальных данных нет), то даже с кривым клоком хосту удается поддерживать синхронизацию.

 

Не подскажите куда в этом коде вставить посылки ZLP?

 

У меня есть подозрение, что в EP0 они эти посылки вставили перед каждой отправкой или при инициализации.

А в EP1 EP2 этого нет - поэтому данные и теряются.

usbhs_device.zip

[Шаманъ 0]

Не подскажите куда в этом коде вставить посылки ZLP?

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

 

Теперь про ZLP. Когда посылать нечего по правилам точка выставляет NAK, я вместо этого посылал ZLP пакеты. Куда именно вставлять в код Вам должно быть виднее - я "воевал" с STM32, и код был написан мной с нуля, поэтому таких вопросов не возникало. Могу предположить, что начиная со строки 1923 стоит посмотреть - там судя по коду и комментариям как раз "деактивируют" точку после окончания передачи.

 

У меня есть подозрение, что в EP0 они эти посылки вставили перед каждой отправкой или при инициализации.

А в EP1 EP2 этого нет - поэтому данные и теряются.

Если все ок с железом, то пустые пакеты нужны только там, где нужны по протоколу. В EP0 ZLP пакеты отправляются как подтверждения приема данных, там они нужны по-любому. С другими точками они обычно нужны только как признак окончания передачи, если длина посылки кратна размеру пакета.

[Alexey_N 0]

А в EP1 EP2 этого нет - поэтому данные и теряются.

Так чем дело кончилось, - удалось победить этот камень?

[_4afc_ 24]

Так чем дело кончилось, - удалось победить этот камень?

 

Кончилось заменой кварцевого резонатора на другой тип.

 

Камень изначально тактировался от резонатора типа CSTCE.

Было опробовано 5 партий этих резонаторов с маркировками на корпусе h,t,x,v,g в режиме HS:

 

CSTCE_h 11.9451MHz (-4575ppm) - нестабильное соединение, чтение невозможно;

CSTCE_t 11.9487MHz (-4279ppm) - стабильное соединение, чтение с ошибками;

CSTCE_x 11.9515MHz (-4042ppm) - стабильное соединение, чтение с ошибками;

CSTCE_v 11.9566MHz (-3621ppm) - стабильное соединение, чтение с ошибками;

CSTCE_g 11.9590MHz (-3417ppm) - стабильное соединение, чтение без ошибок.

 

Поскольку резонатор CSTCE с маркировкой на корпусе g закупался много лет назад, остатков бы не хватило на серию, a в продаже его не найти.

Была выбрана замена AMB10 с маркировкой на корпусе AH6G частотой 11.9998MHz (-21ppm) - стабильное соединение, чтение без ошибок.

 

PS: Что интересно CY7C68013 прекрасно работал в режиме HS от кварца с частотой 24.0032 (+133ppm)...