Анализируют ли стандартные CAN анализаторы ID и принятые данные, точнее ту часть данных и ту часть ID которые были приняты до установки доминанты (ошибки битстаффинга), в сети другими устройствами? Это чтобы по ID узнать полудохлый блок в сети.
Если таких анализаторов нет, то есть какая то микросхема CAN интерфейса, которая точно позволяет это делать - pdf на неё смотрел, но тогда это мне не нужно было. А сейчас её тип вылетел из головы.
А CAN интерфейс у МК - сильно упрощённый. На мой взгляд, навряд ли у какого из МК с CAN такая возможность есть. Но если есть, то это тоже вариант.
Или уж свой самодельный CAN на базе ATmega48 доработать? Там это легко делается, но с передачей полученной информации проблема.

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

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

можно самому написать на ПЛИСине - есть проект opencan на опенкоресах - клон SJA1000, впринципе, можно расковырять
более быстрый и дешевый вариант - купить китайский USB логический анализатор, с него сливать в ПК, а там своим скриптом проанализировать

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

и не забутьте еще о возможности 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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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