Jump to content

    

Размышления на тему блокировки CAN bus

Реализую драйвер линукс Can, в процессе возникли мысли о том что шина в ряде ситуаций может быть завешена наглухо. Хотелось бы понять как минимизировать вред от таких ситуаций.

 

Рассмотрим случай 1: ретрансмисии + bus-off

Есть узлы 1 и 2, они обмениваются пакетами в обе стороны, т.е

1<---->2. Других узлов нет.

Теперь внешним воздействием (придурки!) во время работы кабель разрывается, причем так что шина на стороне 1 оказывается оборвана и на стороне 2 закорочена, т.е так:

1----X |----2.

На узле 1 возникает No ack error, которая приведит к ретрансмиссии.

Узел 2 преходит в Bus-off.

В реализациях передатчиков я ни разу не видел таймаут на передачу, также в дш черным по белому пишут что no ack error не приводит к bus-off. На практике все что есть под рукой с чипами sja1000, lpc, stm32 ведут рестрансмиссию бесконечно.

Через какое-то время те же придурки которые разорвали кабель спохватившись восстановили его целостность.

Теперь 1 флудит ретрансмиссиями а 2 пытается выполнить процедуру bus-off recovery для которой требуется 128*11 рецессивных бит. Очевидно что 2 никогда не выйдет из bus-off а 1 никогда не получит ack. Глухой завис. А теперь представим что узел 1 физически или организационно недоступен. Все, можно стреляться.

 

Случай 2: проблема приоритетов

При высокой загрузке сети высокоприоритетными пакетами попытка отправки каким либо узлом низкоприоритетного пакета приведет в блокировке очереди передачи/фифо/мэйлбоксов этого узла. Отменить передачу одного сообщения может быть проблематично, сбрасывать все фифо в многозадачной системе нельзя. Например как обрабатывать подобную ситуацию в линукс оставаясь в рамках Socket CAN я вообще не представляю.

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

 

Share this post


Link to post
Share on other sites
В реализациях передатчиков я ни разу не видел таймаут на передачу

Те, кто поддерживает TTCAN, т.е. синхронизацию времени между девайсами по CAN, не должны вообще повторов делать.

А что мешает самому таймаут сделать?

Share this post


Link to post
Share on other sites
Те, кто поддерживает TTCAN, т.е. синхронизацию времени между девайсами по CAN, не должны вообще повторов делать.

А что мешает самому таймаут сделать?

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

Не предусмотрено в апи linux Socket CAN. Изделие и драйвер должны работать в соответствии со стандартными апи.

Не предусмотрено в протоколе верхнего уровня Canopen, прикладной софт есть, обкатан и изменениям не подлежит.

Меняется только кан контроллер и драйвер. Исходя из этого действия драйвера должны быть прозрачными для софта и не затрагивать трафик насколько это возможно.

Share this post


Link to post
Share on other sites
Случай 2: проблема приоритетов

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

Share this post


Link to post
Share on other sites
Меняется только кан контроллер и драйвер.

Вот пусть драйвер и проинициализирует контроллер в режим TTCAN, и никаких автоматических повторов уже не будет.

Share this post


Link to post
Share on other sites
В реализациях передатчиков я ни разу не видел таймаут на передачу, также в дш черным по белому пишут что no ack error не приводит к bus-off. На практике все что есть под рукой с чипами sja1000, lpc, stm32 ведут рестрансмиссию бесконечно.

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

 

Кстати

Через какое-то время те же придурки которые разорвали кабель спохватившись восстановили его целостность.

Как вы предлагаете восстановать кабель, предварительно не убрав КЗ с узла 2? За 128*11 бит это надо слишком быстрым быть. То есть при восстановлении кабеля узел 2 должен уже восстановиться и все пройдет пучком.

Реально Вы пробовали промоделировать такую ситуацию?

 

Случай 2: проблема приоритетов

При высокой загрузке сети высокоприоритетными пакетами попытка отправки каким либо узлом низкоприоритетного пакета приведет в блокировке очереди передачи/фифо/мэйлбоксов этого узла. Отменить передачу одного сообщения может быть проблематично, сбрасывать все фифо в многозадачной системе нельзя. Например как обрабатывать подобную ситуацию в линукс оставаясь в рамках Socket CAN я вообще не представляю.

Эта проблема старая. Чтобы этого не было CAN реально нельзя загружать на больше, чем 30-50% пропускной способности. Это писали еще на заре CANостроения.

Share this post


Link to post
Share on other sites
...На практике все что есть под рукой с чипами sja1000, lpc, stm32 ведут рестрансмиссию бесконечно.

По-моему в STM32 "бесконечность" настраивается. Этот режим можно включить или выключить. Там по превышению ошибок, передача останавливается.

Share this post


Link to post
Share on other sites
По-моему в STM32 "бесконечность" настраивается. Этот режим можно включить или выключить. Там по превышению ошибок, передача останавливается.

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

Share this post


Link to post
Share on other sites
Я это тоже сначала хотел предложить, но по даташиту пробежался и не нашел там такого. Зато прерываний - по любому чиху есть.

Давно это было... Режим настраивается

AN_InitStructure.CAN_ABOM = DISABLE;

Для STM32F407 при DISABLE передача останавливалась.

Share this post


Link to post
Share on other sites

1 насколько я помню в стандарте есть требования на количество ошибок в шине - и если perr больше чегото там (не помню но по моему порядка 10e-6) то такая шина считается неработоспособной и на нее не расчитывают

2 ничто не мешает (как вам написали выше работать по TXERR и RXERR) просто тупо их брасывая не забутьте только отменить передачу перед сбросом

3 ну а уж про таймауты это ваще дело что назывется ваше и вашей системы

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this