Перейти к содержанию
    

Влияние JTAG-а на работу программы

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

За все время работы с мегами (с икс-мегами в частности) впервые столкнулся с таким абсолютно дурацким "приколом".

Суть такая: проц (ATXmega128A3U) коннектится к Bluetooth модулю через UART, используя AT-команды, при этом идет индикация подмаргивающим светодиодом, BT-модуль ищет пару, соединяется, после чего проц включает USB, проводит энумерацию в системе, светодиод загорается постоянно.

В целом ничего смертельного. Написал, отладился...

Отцепляю JTAG... и вижу... к паре BT никаких попыток соединения, светодиод продолжает моргать, в системе устройства нет... Снова подцепляю JTAG, запускаю... все работает со свистом... Отцепляю... где-то встает намертво. Методом "светодиодоподмаргивания" нашел место. Выяснилось, что часть обмена проц даже успевает провести, но там длина команд и ответов маленькая, как только строки начинаются длиннее, начинается ерунда.

Перецепил JTAG (USBJTAG MkII) в PDI... Все работает...

Вариантов в голове крутится много, начиная от плохих земель, кончая "уезжанием" скорости UART-а. Но зацепиться пока не знаю за что. Вдруг кто уже сталкивался с похожими приколами? Может что присоветуете?

P.S. По сути не думаю, что там что-то страшное, но состояние слегка близко к панике, ибо железяку бы сегодня надо доделать, а еще и день короткий.

P.P.S. Посылаю строки через DMA UART-а, принимаю побайтово, через прерывания, так как заранее длина приемной посылки не известна достоверно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вариантов в голове крутится много, начиная от плохих земель, кончая "уезжанием" скорости UART-а.

 

...

 

P.S. По сути не думаю, что там что-то страшное, но состояние слегка близко к панике, ибо железяку бы сегодня надо доделать, а еще и день

короткий.

P.P.S. Посылаю строки через DMA UART-а, принимаю побайтово, через прерывания, так как заранее длина приемной посылки не известна достоверно.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

DMA говорит о отовности при начале передачи последнего байта, а какая-то реакция должна произойти после его передачи?

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

как только строки начинаются длиннее, начинается ерунда.

Но зацепиться пока не знаю за что

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вот за это и цепляйтесь.

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

От чего тактируемся?

Для USB у XMeg почти без вариантов: от внутреннего RC-шника, который причем раскачан до 48МГц. От него же, через делитель идет и системный клок, и для периферии.

P.S. В целом, проблема решена. По идее Genadi Zawidowski я вставил внутри основного цикла паузу на 0,5мсек (потом уменьшу). К моему удивлению, все сразу начало работать. Теперь бы еще все протестировать с самого начала, как бы такие паузу чего другого не зацепили

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Ожидание конца передачи там есть изначально... это как бы априори... Тут, похоже, нужны именно ПАУЗЫ. Такое чувство, что проц на модуле... как бы сказать... не очень

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

P.P.S. Исходя из мысли о том, что не справляется проц модуля я постарался его разгрузить, и отключил эхо у модуля. После чего все заработало всех всяких пауз.

Изменено пользователем stalko

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...