Jump to content

    

Анализатор ошибок в CAN сети.

Recommended Posts

galjoen

Анализируют ли стандартные CAN анализаторы ID и принятые данные, точнее ту часть данных и ту часть ID которые были приняты до установки доминанты (ошибки битстаффинга), в сети другими устройствами? Это чтобы по ID узнать полудохлый блок в сети.

Если таких анализаторов нет, то есть какая то микросхема CAN интерфейса, которая точно позволяет это делать - pdf на неё смотрел, но тогда это мне не нужно было. А сейчас её тип вылетел из головы.

А CAN интерфейс у МК - сильно упрощённый. На мой взгляд, навряд ли у какого из МК с CAN такая возможность есть. Но если есть, то это тоже вариант.

Или уж свой самодельный CAN на базе ATmega48 доработать? Там это легко делается, но с передачей полученной информации проблема.

Share this post


Link to post
Share on other sites

novikovfb

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

Share this post


Link to post
Share on other sites

yes

естественно есть - видел у Lecroy-а например. есть всякие специализированные софты и т.д.

но в простых "кэн снифферах", типа марофоновского нет такой возможности - там микроконтроллер стоит, битые фреймы никак не принимаются

 

можно самому написать на ПЛИСине - есть проект opencan на опенкоресах - клон SJA1000, впринципе, можно расковырять

более быстрый и дешевый вариант - купить китайский USB логический анализатор, с него сливать в ПК, а там своим скриптом проанализировать

 

Share this post


Link to post
Share on other sites

net

битые кадры принимаются любым контроллером там только два раза придется принимать по прерываниям

так как данные надо выбрать при приходе следующего пакетта

но дело в том что ошибку может пораждать совсем не тот кто передает

и вам это мало поможет

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

и этого когото вы никогда не узнаете при анализе шины

 

и не забутьте еще о возможности 1: Listen Only Mode -- the controller gives no acknowledgment on CAN, even if a

message is successfully received. Messages cannot be sent, and the controller

operates in “error passive” mode. This mode is intended for software bit rate

detection and “hot plugging

Share this post


Link to post
Share on other sites

yes
битые кадры принимаются любым контроллером там только два раза придется принимать по прерываниям

 

а это проверяли или предполагаете?

 

просто в контроллере обычно FIFO на 2-3 CAN сообщения, и в это FIFO попадает только то, что прошло acceptance filter, то есть было принято полностью.

я специально не смотрел, но впечатление такое, что ничего в этом фифо нету по error-у. да и прерывание по ошибке не на всякий битый фрейм генерируется (это для LPC и STM CAN контроллеров)

 

 

Share this post


Link to post
Share on other sites

syoma

Вроде как у некоторых контроллеров (помомему STM32F10X) даже если нога настроена на CAN прием, можно спокойно читать ее состояние из программы. Поэтому я бы написал простенькую логгер-программу, которая бы постоянно со скоростью хотя бы раз в 5 больше скорости CANа семплировала состояние этой ноги и пихала в буфер. И если CAN-контроллер генерит прерывание по ошибке - в буфере будут лежать последние принятые биты перед ошибкой.

Это в идеале. Сам не проверял.

 

Еще можно по прерыванию ошибки можно дергать какой-нибудь свободной ногой МК и по ней синхронизировать осциллограф, подключенный к CANу. Ну а потом глазками вычислять ID.

Share this post


Link to post
Share on other sites

net
а это проверяли или предполагаете?

 

просто в контроллере обычно FIFO на 2-3 CAN сообщения, и в это FIFO попадает только то, что прошло acceptance filter, то есть было принято полностью.

я специально не смотрел, но впечатление такое, что ничего в этом фифо нету по error-у. да и прерывание по ошибке не на всякий битый фрейм генерируется (это для LPC и STM CAN контроллеров)

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

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

а пробелму выявили путем анализа аппаратуры в сети и программ настройки can контроллеров

 

все(сниффер) сделано на lpc 2294 двумя каналами смотрит в can шину и одним can на pc где производится разбор полетов

 

на шину вешается два can потому что 1 can работает в only listen mode - чтобы ничего не портить в работе шины

а 2 can подключается если нужно чтото сгенерить в шину

 

3 can пересылает все на pc где все протоколируется и смотрится в удобном виде и через него же задается режим генерации нужных пакетов в шину если нужно

 

битые пакеты прекрасно протоколируются(через два прерывания)

 

 

4 "can" хотели под интелектуальный генератор помех задействовать - но пока со всем разбирались пришли к выводу что все это шорох орехов

и надо просто правильно делать железо и писать программы

и никаких снифферов не нужно :biggrin:

Share this post


Link to post
Share on other sites

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

CAN.rar

Share this post


Link to post
Share on other sites

novikovfb

моя проблема решилась совсем другим способом: одно из устройств на шине из-за разгильдяйства разработчика на 2-3 секунды выставляло доминантный уровень (сделали CAN на ПЛИС, пока не запрограммируется - держит "0").

Edited by novikovfb

Share this post


Link to post
Share on other sites

net
моя проблема решилась совсем другим способом: одно из устройств на шине из-за разгильдяйства разработчика на 2-3 секунды выставляло доминантный уровень (сделали CAN на ПЛИС, пока не запрограммируется - держит "0").

примените драйвера с отключаемым тайм аутом и вообще проблем не будет - а то так и будете виснуть

 

Share this post


Link to post
Share on other sites

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

в битом кадре данные читаются - если у вас 0 то вы не доделали программу чтения битых кадров

 

Share this post


Link to post
Share on other sites

в битом кадре данные читаются - если у вас 0 то вы не доделали программу чтения битых кадров

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.