Доброго времени суток всем!
За все время работы с мегами (с икс-мегами в частности) впервые столкнулся с таким абсолютно дурацким "приколом".
Суть такая: проц (ATXmega128A3U) коннектится к Bluetooth модулю через UART, используя AT-команды, при этом идет индикация подмаргивающим светодиодом, BT-модуль ищет пару, соединяется, после чего проц включает USB, проводит энумерацию в системе, светодиод загорается постоянно.
В целом ничего смертельного. Написал, отладился...
Отцепляю JTAG... и вижу... к паре BT никаких попыток соединения, светодиод продолжает моргать, в системе устройства нет... Снова подцепляю JTAG, запускаю... все работает со свистом... Отцепляю... где-то встает намертво. Методом "светодиодоподмаргивания" нашел место. Выяснилось, что часть обмена проц даже успевает провести, но там длина команд и ответов маленькая, как только строки начинаются длиннее, начинается ерунда.
Перецепил JTAG (USBJTAG MkII) в PDI... Все работает...
Вариантов в голове крутится много, начиная от плохих земель, кончая "уезжанием" скорости UART-а. Но зацепиться пока не знаю за что. Вдруг кто уже сталкивался с похожими приколами? Может что присоветуете?
P.S. По сути не думаю, что там что-то страшное, но состояние слегка близко к панике, ибо железяку бы сегодня надо доделать, а еще и день короткий.
P.P.S. Посылаю строки через DMA UART-а, принимаю побайтово, через прерывания, так как заранее длина приемной посылки не известна достоверно.

JTAG возможно что-то замедляет... DMA говорит о отовности при начале передачи последнего байта, а какая-то реакция должна произойти после его передачи? Проверка: если понизить скорость обмена с BT, перестать должно работать в любом случае, не только без j-tag...

Да, собственно, никакой... Послал, и кручусь, жду, пока наберется строка ответа от модуля. И только после проверки ответа будет другая команда (если будет). Довольно примитивная машина состояний: передал-принял-передал-принял...

Об этом я уже думал, но это не так просто, к сожалению (если Вы про физическую скорость UART-а, а не про паузы между посылками, конечно). Кстати, вот плохо, что у XMeg нельзя настроить паузу между байтами в DMA. У АРМов, если я не путаю, ее можно задать...

Вот за это и цепляйтесь. От чего тактируемся?

Ясно, что за это цепляться, знать бы чем

Для USB у XMeg почти без вариантов: от внутреннего RC-шника, который причем раскачан до 48МГц. От него же, через делитель идет и системный клок, и для периферии.
P.S. В целом, проблема решена. По идее Genadi Zawidowski я вставил внутри основного цикла паузу на 0,5мсек (потом уменьшу). К моему удивлению, все сразу начало работать. Теперь бы еще все протестировать с самого начала, как бы такие паузу чего другого не зацепили

Я-то думал, Вы разберётесь... и вместо паузы где-то добавите ожидание конца передачи. Но понятно, день короткий...

Ожидание конца передачи там есть изначально... это как бы априори... Тут, похоже, нужны именно ПАУЗЫ. Такое чувство, что проц на модуле... как бы сказать... не очень
P.S. Хотя, подумал над Вашей фразой... Мы явно говорим о разных вещах... Я о проверки на окончание передачи перед новой посылкой, но в Вашем контексте это не имеет смысла... Вы предлагаете ожидать окончания передачи прежде чем начинать прием (или не прием, а ОБРАБОТКУ?) ответа? Извините, а смысл? Что это дает, собственно?
P.P.S. Исходя из мысли о том, что не справляется проц модуля я постарался его разгрузить, и отключил эхо у модуля. После чего все заработало всех всяких пауз.

Сообщение отредактировал stalko - Feb 25 2013, 09:03

При той информации, что Вы дали о задаче, я мог предположить только то, что где-то алгоритм зависит от TX EMPTY (не от TX READY) - судя по характеру проявлений и по тому, что "пауза помогла".