Здравствуйте. Столкнулся со следующей проблемой при работе с USART-ом:
Собрал на нем интерфейсную плату USB - USART. Прошивка написана так, что при подключении платы к USB в системе появляется виртуальный serial порт, в который можно обычными
способами писать читать из него. Соотвтественно прошивка всегда ждет данных от PC (через BULK точку) и высылает их сразу в UART, и паралельно ждет данные с UART-а и отсылает их
по BULK-точке на PC. В общем обычная схема USB-Serial.

Проблема в следующем, вход RXD0 микроконтроллера у меня берется не напрямую от серийного устройства а через обычный 8 в 1 демультиплексор,
у которого соответственно есть три адресных пина АBC. В демультиплексоре использваны только несколько пинов, остальные - на землю. Итого, если при включении питания схема правильно проводит RX от серийного устройства к RXD0 пину микроконтроллера - проблем никаких не возникает, все работает прекрасно, данные из USART-а вычитываются прошивкой и далее как описано выше.
Однако, если при подаче адреса на демультиплексор например так, что кратковременно на RXD0 поступит 0 от заземленных входов то... вот тут и начинаются странности. Если после этого снова подать правильный адрес на демультиплексор , т.е. RX теперь будет правильно проходить до RXD0 пина - то на ножке RXD0 микроконтроллер удерживает уровень 0 - уже вне зависимости от того что имеем на выходе демультиплексора - этот порт притягиватся к земле самим микроконтроллером. Со стороны пошивки такое состояние USARTa выглядит как постоянная ошибка FRAME - т.е. постоянный 0 уходит и в перефирию USART-a и соответственно от этого и ошибка FRAME.

Уже перепробовал кажется все, перечитал документацию и все регистры относительно PIO и USART - результат один, что не делаю (ресет ресивера, вкл/выкл ресивера, переконфигурирование RXD0 пина во вход или выход и обратно в режим USARTa) - RXD0 остается утянутым на землю и соотвтественно чтение RX не срабатывает. Что характрено - если теперь переконфигурировать RXD0 пин как вход, то по прежнему тестером измеряется 0 на ножке RXD0 (!) хотя в обычном состоянии напряжение на пинах микроконтроллера сконфигурированых как вход имеет значения характреные при измерении в Z-состоянии.
Пробовал выпаивать демультиплексор - подавая RX напрямую и руками коротил кратковременно на землю - все повторяется в точности, т.е. демультиплексор как возможная проблема - отпал - это не выход демультиплексора имеет 0, это микроконтроллер установил его на ножке RXD0.

Наскольно я понимаю это либо какая-то защита от перегрузки или еще что-то, в общем лечится только выкл/вкл питания схемы.
Не исключаю что я что-то упустил, может есть возможность програмно сбросить такое "странное" состояние порта. Поскольку я меряю на ножке постоянный 0 и аналогично контроллер USART тоже читает 0 значит этот ноль устанавливается где-то внутри PIO контроллера. Только гле? У меня идеи закончились

Буду очень благодарен если кто поделится свом мнением на этот счет.

Сообщение отредактировал Albun - Jun 3 2009, 16:55

Это наблюдается на одном экземпляре, или на нескольких?


А что получается, если сконфигурировать как выход, и выставить '1'?

Пробовал перепаивать микроконтроллер - ситуация не поменялась, значит не чип.
Если конфигурирую его (пин) в таком состоянии как выход - то при установке нуля имеем ноль, единица - дает напряжение как на Z-выходах или на входах
(т.е. в реальных величинах у меня 3.3V питание IO, в обычном (не этом странном состоянии) уровень "1" = 3.3V, на пинах сконфигурированных как вход = ~2.8V,
и на RXD0 после ошибки - тоже ~2.8V). Вот такая аномалия.
Конфигурирую вход/выход/периферия одними и теми же функциями, все работает, в том числе и на RXD0, но вот только до КЗ, после - так как я описал выше.

Сообщение отредактировал Albun - Jun 3 2009, 16:29

2.8V - это не "напряжение, характерное для вывода в Z-состоянии", а VPull-up. Кстати, пробовали эти самые pull-up'ы отключать?
Тактирование PIO, как я понимаю, включено? (не должно ни на что влиять, но так, на всякий случай)
И последний вопрос: ревизия кристалла какая?

Сорри, не знал, учту.

Да, c pull-up игрался по полной - влючал и отключал во всех трех режимах - в режиме входа выхода и периферии (USARTa) - результата ноль
Строчка кода с включением тактирования у меня сразу в процедурах конфигурирования, так что включено тоже, хотя оно нужно насколько я знаю только для чтения IO линии
По поводу ревизии кристалла не уверен как ее посмотреть. Полная маркировка на чипе такая - AT91SAM7S256 AU-001 58818C 0533 5R2368

Сообщение отредактировал Albun - Jun 3 2009, 16:53

58818C - самый первый выпуск. Можно попробовать поискать что-нибудь поновее, хотя как-то трудно представить, чтобы такой глюк кристалла остался незамеченным.

В каком состоянии у Вас выводы PA0-PA2?

Используются для упровления логикой платы, т.е. все три конфигурируются при старте как выходы. Но я не думаю что это связано с ними.

А кто его знает? Единственное, чем примечателен PA5, это заведенным на него сигналом PGMRDY FFPI. PA0-PA2 как раз принимают участие в разрешении этого интерфейса, и один косяк из ерраты как раз связан с PA1. Несколько притянуто за уши, но я бы проверил.

Так, в общем разобрался в чем причина была. Мой огромный недосмотр.
По всей видимости когда выпаивал демультиплексор и коротил RXD0 на землю вручную что-то не правильно измерил. Сегодня снова снял все микросхемы с платы и попробовал закоротить - никакой 0 не держался на RXD0, все было нормально. После этого вычислить ошибку стало просто. Вернулся к демультиплексору и точно, оказалось что человек который разводил плату "потерял" разрешающий вывод G и в результате ножка "висела" в воздухе. Поэтому и какой адрес не подавался на демультиплексор все-равно на выходе был 0 который потом как-то хаотично мог пропустить сигнал RX а мог и не пропустить.

В общем вопрос снимается.