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

Я использую 16-битный MCU, PIC24HJ64GP504 , чтобы написать приложение на основе CAN. По сути, это связь между моей платой и другим узлом, которая постоянно отправляет данные на мою плату с использованием CAN со скоростью 1 Мбит / с. Я настраиваю модуль ECAN в моем PIC24 для работы на скорости 1 Мбит / с. Я написал код таким образом, что в течение первых 10 мс модуль ECAN будет принимать все сообщения, поступающие с другой стороны, и после этого я перенастроил модуль ECAN для приема только тех сообщений с идентификатором сообщения 0x13.

Теперь возникает проблема. Другой узел и моя плата включаются одновременно. Другой узел начинает передавать сообщения примерно через 40 мс после включения питания. Но я не могу получить какое-либо сообщение об этом на моей доске. Теперь, если я сначала включу свою плату, дадим ей некоторое время, чтобы перенастроить модуль ECAN с новыми фильтрами и настроить, а затем включить другой узел, тогда все работает отлично.

Теперь самое странное ... Если у меня есть анализатор шины CAN, подключенный между моей платой и другим узлом, и даже если я включаю оба узла одновременно, все работает нормально ... нет необходимости сначала включать плату. Я пробовал это с тремя различными анализаторами шин от разных производителей и получил те же результаты.

Мне кажется, что во время переконфигурации модуля ECAN требуется некоторое время, чтобы успокоиться. А с введением в шину анализатора шины это время как-то сокращается, так что все работает отлично. Но я не уверен, что именно проблема может быть.

Я боролся с этой проблемой в течение последних семи дней.

PS: сегодня я проверил с областью действия и обнаружил, что если другой узел начинает передачу через 170 мс после включения питания, то все работает нормально. До этого мое устройство не получало от него никаких сообщений, если не подключен анализатор шины. Хуже всего то, что я не могу отложить передачу другого узла, прошивка этого узла проприетарна.

Также я прочитал сегодня на форуме, что CAN нужен резистор 120 Ом на узле, чтобы он работал (даже если у моего узла его нет, и он работает нормально, если у него есть время для настройки после перенастройки). Я подозреваю, что введение шинного анализатора каким-то образом изменяет некоторые электрические параметры сети, так что время, необходимое моему узлу для установления после реконфигурации, сокращается. Но я не уверен.. :(

Вы где-то "читали на форуме", что для шины CAN нужны резисторы? Шутки в сторону!!?

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

Спирсон прав, но не по той причине. Дифференциальная шина CAN, которую вы, скорее всего, имеете (вы не сказали, какой интерфейсный чип вы используете, но, вероятно, у вас есть стандартная дифференциальная шина CAN, управляемая чем-то вроде MCP2551 на каждом узле), требует сопротивления между линиями. Это происходит потому, что рецессивное состояние сигнализируется двумя линиями, пассивно соединенными вместе, и доминирующее состояние, которое они активно разделяют. Резисторы между линиями в этом смысле эквивалентны нагрузочному резистору на линии с открытым коллектором. Если что-то не соединяет линии, когда ничто не ведет автобус, автобус не работает.

Резисторы также действуют как терминаторы, как указал Спирсон. Вы обычно используете витую пару для двух шинных линий. Это имеет сопротивление около 120 Ом. Дифференциальная шина CAN этого типа определена так, чтобы между линиями было 60 Ω в качестве сближения, так что она может быть реализована с 120 Ω на каждой для завершения шины и предотвращения отражений.

При нормальной работе CAN узел будет повторять свою передачу до тех пор, пока не получит подтверждение ACK или не будет превышено число ошибок. Когда к сети подключен анализатор CAN, он выдаст бит ACK, когда обнаружит кадр от первого узла, что сделает передачу успешной. Если вы используете Microchip CAN BUS Analyzer, вы можете настроить его на режим «только для прослушивания», что означает, что он не будет выдавать биты ACK, поэтому не влияет на сеть. Таким образом, вы должны иметь возможность видеть повторяющийся кадр CAN на дисплее анализатора, пока второй узел не выдаст ACK или первый узел не прекратит передачу из-за количества ошибок.

Бит ACK будет установлен принимающим узлом (если кадр является полным и правильным) независимо от какой-либо фильтрации адресов.

Скорее всего, ваш первый узел находится в состоянии ошибки из-за того, что кадр не подтвержден. Вы должны обнаружить это в программном обеспечении, используя регистр CiINTF. Вы также можете настроить PIC на выдачу прерываний для условий ошибки, используя регистр CiINTE.

Если ваша область не декодирует кадры CAN, попробуйте анализатор Saleae Logic . Он декодирует кадр CAN и покажет бит ACK / Error. Он был намного надежнее, чем анализатор Microchip CAN.

В кадре CAN имеется слот ACK (два бита). Если узел A передает данные и на шине есть пять других узлов, после передачи, какой бы узел ни принял кадр, он поместит доминирующий бит в слот ACK. Это указывает на то, что сообщение было успешно передано. В противном случае контроллеры CAN считают это ошибкой на шине.

Когда вы добавляете анализатор CAN, он отправляет ACK на передатчик. Передатчик считает, что шина исправна и продолжает передачу. В отсутствие CAN-анализатора, когда вы переконфигурируете свой CAN-контроллер, передатчик не получает ACK и думает, что на шине произошла ошибка, поэтому он прекращает передачу.

Я надеюсь, что вы поняли.

Убедитесь, что ACK получает правильно. Также старайтесь не выключать CAN-ресивер полностью во время перенастройки.

Другой трюк (я не уверен, что он будет работать всегда) - отправка нулевого DLC и нулевого идентификатора кадра после перенастройки. Это сообщит узлу передатчика, что шина активна, и он начнет передачу.

Примечание: резистор 120 Ом ОБЯЗАН !!! , Оконечное сопротивление - важная вещь на ЛЮБОЙ шине.