CAN трансивер ADM3053 не переводит шину в доминантный уровень при установке контроллером соответствующего низкого логического уровня в передающей линии TxD. (Контроллер выставляет ACK на TxD, а в линии это не отражается.)
Примерно 1 раз на 10000 посылок. Наблюдается на 18 платах. C чем это может быть связано?

А как вы это проверяете в линии? В смысле, что подключено к шине CAN?

Ошибка исследуется на стенде. собранном по схеме на рис. 1. Сигналы контролируются осциллографом. Осциллограммы приведены на рис. 2.Прерывание по обнаружению ошибки контроллером запускает одиночное измерение осциллографа. Луч сигнала прерывания приходит на 1 канал, синий цвет на осциллограммах. Передающие TxD линии микроконтроллера подключены к 2 и 4 каналам, на осциллограммах показаны голубым и зеленым цветами. Дифференциальный сигнал, измеренный в шине CAN, подключен через дифференциальный щуп и показан на осциллограммах пурпурным цветом. Доминантный уровень шины показан высоким уровнем сигнала на осциллограммах.

На схеме не отражены терминаторы.
А они подключены в реальности?

подключены.

Тогда посмотрите питание осциллографом - нет ли просадов по питанию трансивера и т.п. неприятностей.
Или же радикально: попробуйте для проверки любой другой простой трансивер, дабы определиться, в нем ли дело.

Добрый день!
Я работаю я той же конторе что и EvgeniyCH. Параллельно с ним начал свою разработку на ADM3053.
Моя разработка - это модернизация старой платы, на которой стоят CAN-контроллеры SJA1000 и раньше стояли оптроны, DC/DC конвертер и CAN-приемопередатчик TJA1050 (PCA82C250). Заменил оптроны, DC/DC и TJA1050 на ADM3053 и столкнулся с той же проблемой что и у EvgeniyCH. Т.е на старой плате все работает, а на новой плате наблюдается ситуация - когда на вход ADM3053 СAN-контроллер передает 0 (домин. уровень), а ADM3053 передает на шину вместо доминантного уровня рецессивный. Это приводит к появлению кадра ошибки и повтору кадра (повторный кадр передается успешно). Глюк наблюдается стабильно в слоте ACK (т.е. трансивер не передает на шину подтверждение приема, хотя на его вход CAN-контроллер это подтверждение передает).
Частота глюка увеличивается при увеличении байт данных в кадре и при охлаждении микросхемы.
Уменьшается до нуля при принудительном подогревании микросхемы.
Пробовали разные микросхемы с разных партий, покупали у оф. дистрибьютера AD.
Частота глюка разная от микросхемы к микросхеме, лучшее что видел - глючит только при охлаждении....
Может у кого есть положительный опыт использования этой микросхемы - дайте посмотреть схему включения, plz
или может кто что посоветует....
P.S. параллельно переписываемся и с AD. Они пытаются повторить этот глюк.

Может при замене оптронов (если это была развязка CAN) изменились временные задержки сигнала, и надо пересчитать бит-тайминги?
Еще вариант, попробовать меньшую скорость передачи, как это скажется.

Год назад разработал устройство с ADM3053 в связке c MSP430 и MCP2515. При тестировании железа совместно с программным обеспечением ничего толком не работало. Произошла крупная разборка с программистами и начальством. При этом я был один, кто утверждал, что все в железе нормально. Выдвигались все новые и новые идиотские аргументы - просадка питаний, терминаторы, некорректные задержки, неправильный ресет и т.д. Подключил вместо входного источник Vio и изолированного встроенного источника Visoin внешние источники - работало также плохо. Начальство распорядилось арендовать осциллограф Агилент с CAN программным анализатором. Через несколько дней все заработало как надо при использовании штатного включения ADM3053 в соответсвии с дата шит. Никто не извинился. Что там нашли программисты - знаю поверхностно: некорректная инициализация протокола. Устройство выпускается малыми сериями 200 штук в квартал - никаких проблем.
Ток что сочуствую AD в их повторении Ваших проблем.
Замечу, что за 20 лет использования компонентов AD никогда не было проблем. А вот по поводу Microchip - у меня болшое предубеждение, так как каждый раз при использовании чипов этой компании у программистов возникали проблемы.

бит -тайминги правильные
при уменьшении скорости ошибок меньше
при уменьшении размера пакетов ошибок меньше


В нашем случае проблема именно в железе. И это не говорят программисты и начальство, а разработчики железа видят на осциллограмме. не факт что проблема в AD есть вероятность что микросхемы не AD делал или с платами, схемами что то не так. Ошибок очень мало на программном уровне их не видно, всё прекрасно работает, но они есть.

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

Проблема не с контроллером, а именно с трансивером не выполняется элементарная таблица истинности описанная в DataScheet:
TxD : Bus State
L : Dominant
H : Recessive
Очень редко но Bus State - Recessive при TxD -L , в течении 1мкс при заявленной задержке 120ns.

Не уверен что оно, но выскажу очередное дурацкое предположение.
В качестве развязки микросхемы используют не оптопару, а трансформатор с перекодированием и восстановлением сигнала. Так вот краем уха слышал (на каком то семинаре), что эти штуки могут "подвисать" при большой частоте переключения. Может дребезг на TXD при переключении и вгоняет ее в ступор. Поэтому процесс носит случайный характер и зависит от длины пакета (больше переключений) Хотя по осцилограммам этого (дребезга) не видно.

У меня нечто подобное иногда было, когда использовал "трансформаторные" изоляторы от Agilent и полностью пропало при переходе на AD.

Добрый день!
в общем похоже проблема решилась - помогло заваливание фронта входного сигнала TxD со стороны CAN-контроллера.
Дребезга при переключении никакого не было - был просто очень крутой фронт.
Было время нарастания/спада до/с +5В - 24нс, стало около 60 (поставил конденсатор 1нФ на землю). Глюки с таблицей истинности убрались.
Остался очень интересный глюк - при работе платы с одним терминатором и если при этом она одна линии - посылается один пакет - этот пакет непрерывно передается - если при этом микросхему немного охладить появляются глитчи на CAN-линии длительностью около 200нс. По мере прогрева микросхемы до исх. темп. глитчи двигаются к реальным фронтам и в итоге исчезают.....
С AD я свяжусь этому поводу крутизны фронтов и по глитчам (несмотря на то что этот режим нестандартный - с PCA82C250 такого глюка в этом режиме нет...)