Есть 2-а кнтроллера, М и S они общаются между сосбой по кан. М отправляет на S каждые 60мс посылку, S в свою очередь, отвечает на каждую принятую посылку. ID MSK задана жестко, IDT у каждого свой. Все работает минут 20, а потом порисходит сбой. Или только на М, он перестает принимать посылки от S, хотя S от него все получает и отвечает. Или же обмен прекращается вообще. Может кто сталкивался с подобным? контроллер atmel 128 скокрость минимальная 100Kbps на 8 Мгц. При том вижу на осцилографе, M посылает посылку, S отвечает. Время ответа дышит, то 1мс то 10мс, но иногда ответ перекрывается с запросом, и именно в этот момент может упасть обмен вообще. Но адреса то ID разные и маска жестко задана. Если увелить время когда M шлет запрос, то работает дольше, но очень хотется понять прчину . Даже в отладке ловил, в BUS OFF M не попадает. CANSIT2 показывает что отправка прошда успешно, и я вижу, что S всё принял и ответил правилльно. А М отказывается от него получать данные. Было такое: на М возведен флаг RXOK на мобе который натсроен на прием, но в CANSIT2 никакого события о приеме нет.

Это только общие рассуждения без учета специфики аппаратуры и реализации ПО.

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

вопрос к реализации ПО как , тупая нехватка времени на обработку или срабатывание какого-либо устройства сброса - это повод для размышлений.

Раз ID разные - у вас арбитраж не срабатывает.
У вас линия согласована? 120 ом по обоим концам стоят?

Спасибо за ответы. 120ом стоит. Сейчас я сделал еще проще. M каждый 15мс передает посылку S, а S каждые 22мс передает посылку M, они не привязаны к друг другу. Если посылка дошла, то анализирую первые 2-а байта, они разные должны быть, и говорю что все ОК. Ситуация повторяется, все работает до тех пор пока не переххлеснутся импульсы. Потом данные из моей посылки не доходят, хотя передающий контроллер, получает АСК и говорит что передача прошла успешно! А на принимающей стороне, в прерывание от принимающего моб, он вообще перестает попадать. При том не возникает никаких ошибок. Включил все возможные прерывания по ошибкам, в обработик не попадаю вообще. Типа вес хорошо кан работает передачи проходят успешно. Толкьо вот на принимающей стороне, в прерывание от принимающего моб не попадаю, и данных соответственно нет.
Я думал на счет арбитража, елси возникает арбитраж, ошибки какие то должны возникнуть?
И почему тогда, когда проходит несоклько минут, импульсы на осцилограце опять расходятся, но данные не доходят. Как уже говорил, никаких ошибок, все хорошо, толко в принмающий моб перестает попадает вообще.

1.Канал затыкается только во время накладок - значит одно из устройств проигрывает арбитраж. Если автоматический повтор сообщения включен, то контроллер CAN сам должен повторить сообщение после освобождения шины. Если автоповтор не включен, обрабатывать эту ситуацию должено ПО.
2 Момент. Кто из абонентов канала перестает принимать после накладок?? Тот, у кого больший идентификатор сообщения или оба?? Если устройство, проигравшее арбитраж то см.п.1 одназначно. Если оба (при передаче говорят что все ОК, но не принимают) возможны варианты либо п.1 либо тонкости в настройке модуля. Во втором случае, если контроллеры однотипные, попробовать заменить один из них на НЕЧТО ДРУГОЕ.

Автомотический контроль сообщений я и включал и выключал, ситуация не меняется. Это я так понимаю Режим TTC, по умолчанию он включен. Отключается установкой бита CANGCON=(1<<TTC). Я прямо вижу на осцил., елси он включен и я разрываю линию, физически отсоединив провод, то сразу нафинают валить сообщения. А как только лини включаю то они передаеются именно с той частотой, с которой я их и посылаю. Те это еще раз подверждает что передача завершается типа успешно, хотя на принимающей стороне, я не попадаю на моб настроееннный на прием после конфликта вообще.

Контроллеры полностью одинаковые AT90CAN128. Затыкается именно на прием, вначале один потом втрой, или же могут оба одновременно, почему пока понять не могу....Но чаще первым затыкается тот у которого ID на отправку меньше. А после него проходит пара минут и второй тоже уходит. Елси возникает арбитраж, я в прерывание не попадаю, как мне понять что он произошел и надо что то сделать? Ведь никаких ошибок, все передается, и программа думает что все номально.

А что происходит елси запрещены прерывания на прием от кан и в этот момнет приходит посылка? Я убрал запрет прерываний на прием, и проблема пропала, при том не важно куда я этот запрет ставлю, и сколько он по времени длится. В любом месте кода ставлю: запрет - 1 пустая команда - разрешаю прерывания, и происходит сбой. Как только отключил запрет переваний на прием, всю ночь проработала без сбоев.... Сейчас уменьшил время посылки до 6 мс на каждой строне, отключил ТТС, уже час работает. Импульсы перекрываются, проблем не вижу пока. Логику понять не могу, ну пердположим запрещены прервыания на прием, в этот момент узел проиграл арбитраж, потом же я прервание разрешил, и должен их спокойно обработать и выйти из обработчкиа.

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

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

ну тут ситуация не совсем стандартная, он затыкался только когда был перехлест импульсов. Без всяких ошибок. Так что думаю, что флаги событий тут не при чем.
Вообщем проблема решена, стоит сокроть 500kbps каждую 1мс шлют друг другу, пока ошибок нет, елси так продержутся несоклько дней то все будет хорошо .
Всем большое человеческое спасибо!

С атмеловским CAN не работал, но общие размышления подкину. Посмотрите в сторону прерываний модуля CAN. Вполне возможно, что у Вас есть прерывание проигрыша арбитража, или вообще ошибок на линии. В таком случае, периферия контроллера может ожидать обработки этого прерывания, или хотя бы сброса флага этого прерывания. А вообще - скорости 100 кб, и тем более 500 кб это не такие уж и маленькие скорости для CAN, может быть проблема в длине линии передачи?