1. Заменил ATmega64 на AT90CAN128 у двух своих устройств + добавил КАН приёмопередатчики.
2. Переписал программу (таблица прерываний и обращение к портам).
3. Разобрался (более-менее) с КАН-овскими портами.
4. Написал примитивную посылалку - принималку по КАН.
5. Попробовал - всё сразу заработало!
6. Отрубил у принимающего устройства TXCAN (не передаёт в линию ACK) - начались вопросы:
У принимающего устройства возникает ошибка "ACK error", хотя по описанию (да и логически) должна-бы возникнуть "Bit Error". Устройство-то передаёт в линию 0-й уровень (ACK), а в линии 1.
7. Запретил у принимающего устройства приём адреса генерируемого передатчиком. Судя по описанию в этом случае должна возникнуть общая ошибка - ACK error general (в линии имеется кадр с ресессивным уровнем в бите ACK). Реально у приёмника не возникает никаких ошибок. Пробовал запретить все MOb вообще, проверял разрешение всего, что относится к общим ошибкам - бесполезно.

Особенно волнует отсутствие общей ошибки (планировал использовать), что это - глюк в AT90CAN128, или во мне.

Как раз, передатчик в ACK слоте передает recessive bit, и ждет ACK - dominant, а т.к. устройств больше нет то и появляется ошибка "ACK error"



Фильтры не влияют на поле ACK, error... если контроллер принял фрейм выставляется подтверждение, ошибки.... А уже потом решает выкинуть его или положить в MOB (уже другой уровень).
По ошибкам, полю ACK - можно узнать только состояние физического уровня.

И я именно об этом: приёмник выставляет dominant в ACK слоте, но из-за оторванного провода TXCAN у приёмника этого не получается (ACK остаётся recessive). И у него (у приёмника) возникает ошибка "ACK error" и больше никаких ошибок. Хотя т.к. приёмник установил на шине dominant, потом проверил, а там recessiv, он вроде-бы должен установить ошибку "Bit error". А судя по описанию (как я понял) у приёмника вообще не д.б. такой ошибки как "ACK error". То, что у передатчика возникает ошибка "ACK error" - это понятно.

Я понимаю так:
1. Контроллер принимает фрейм и проверяет проходит-ли он через фильтры.
2. Если проходит - кладёт его в MOb (MOb-ы), устанавливает в слоте ACK - dominant уровень, ошибки устанавливает в соответствующем MOb (MOb-ах) (в тех, в которые фрейм прошёл через фильтры).
3. Если не проходит, или испорчен до такой степени, что определить это (прохождение через фильтры) невозможно - не кладёт его (фрейм) в MOb, не устанавливает в слоте ACK - dominant уровень, ошибки устанавливает в разделе "общие ошибки" = "Stuff Error General", "CRC Error General", "Form Error General", "Acknoweledgment Error General".
A. В моём случае фрейм через фильтры не проходит.
B. Т. к. на шине других устройств нет - в слоте ACK recessive уровень.
C. Но общие ошибки (а именно "Acknoweledgment Error General") не устанавливаются.
Из-за этого невозможно проанализировать шину, что я собирался сделать в отладочных целях.

Все правильно раз нет доминирущего бита, в ACK слоте значит нет подтверждение.
А рвать линю TXCAN - не корректно вы просто отключаете физический уровень. И любая попытка отпрвить что то с этого узла приведет к Bus Off
Ошибка bit error может возникнуть только в слоте данных.

Нет, Контроллер принимает фрейм устанавливает в слоте ACK - dominant уровень, а фильтры, MOB... все это потом.

Я не собирался отправлять, что нибудь с этого узла. Я хотел просто сделать анализатор КАН шины для отладочных целей.

Проверил на железке (в т.ч осциллографом) - не верно (по крайней мере для AT90CAN128). Контроллер (принимающий) если этот фрейм не его (не проходит через фильтры ни в один MOb) - не устанавливает в слоте ACK - dominant уровень (отлично видно осциллографом т.к. провод TXCAN у принимающего всегда в 1). Да вроде и логически д.б. так: если фрейм никем не принят (ни одним MOb) - отправитель видит это по отсутствию dominant в слоте ACK.

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

Для этого есть режим LISTEN ONLY.


Вот выдрежка из даташита на can128
The bit in the ACK slot is sent as a recessive bit and is overwritten as a dominant bit by the receivers which have at this time received the data correctly. Correct messages are acknowledged by the receivers regardless of the result of the acceptance test.
И логически - это ошибка физического уровня. А то что не в один ящик не попало это другой уровень уже.

Еще по поводу физического уровня если неплохой app note от микрочипа.
Controller Area Network (CAN) Basics (можно по этому названию гуглом найти) там описаны все ошибки и когда они возникают или у боша (автора CAN) можно посмотреть - все определно стандартом!

Пробовал режим LISTEN. В этом режиме контроллер никогда не выставляет на КАН шину dominant (внешний провод TXCAN всегда в 1), но внутренний-то сигнал RXDcan устанавливает так, какбудто он выставил dominant на КАН шину. В моём даташите "AT90CAN128_rev_E" эта схема N116 на 235 странице. Это приводит к тому, что на КАН шине ACK=recessive, а MOb принимает его как-будто там был dominant. И, соответственно, бит ошибки AERR в регистре CANSTMOB не устанавливается.

Проверил осциллографом ещё раз - верно. Стоит разрешить КАН и настроить скорость - начинает в ACK слоте dominant устанавливать. Даже если ни одного MOb на приём не настроено. В прошлый раз у меня просто контакт пропадал когда я осциллографом тыкался - всё на соплях запаяно.
Так-что спасибо вам KRS - без вас бы не разобрался.

Но общие ошибки всё равно не возникают. Буду дальше ковырять на досуге. Если наковыряю - сообщу.

А что за общие ошибки?
У физического уровня CAN таких ошибок нет.
Есть Bit error, Stuff error, CRC error, Form error, Acknowledgment error

Может Вы про то что в реализации CAN128 есть регистры MOB а есть General.
Так в даташите написано что
19.7.3Error Setting
The CAN channel can detect some errors on the CAN network.
•In transmission:
The error is set at MOb level.
•In reception:
- The identified has matched:
The error is set at MOb level.
- The identified has not or not yet matched:
The error is set at general level.
After detecting an error, the CAN channel sends an error frame on network. If the CAN channel
detects an error frame on network, it sends its own error frame.

Да, я именно об этом. Думаю, что в данном случае "general errors" можно перевести как "общие ошибки".
В том смысле, что не относящиеся к какому-либо MOb.

Эту выдержку из даташита я понял так: если, или пока ещё, индентификатор не соответствует (ни одному из установленных в принимающих MOb): ошибки устанавливаются на общем уровне. А вы как поняли?

Из этих, общих ошибок (CANGIT), у меня только SERG (Stuff Error General) устанавливается. Это когда я передатчик на 100 кбод настраивал, а приёмник на 1 мбод. При этом каждый бит передатчика длиньше, чем 5 бит приёмника. У КАН, как я понял, max 5 бит одного значения подряд могут быть, 6 - это уже ошибка битстаффинга будет. Но и в этом случае - что-то странное. В регистре статуса приёмника (CANGSTA) бит error passive (ERRP) установлен (устанавливается). То-есть вроде-бы сейчас приёмник в режиме error passive, и только уровнем recessive кадр ошибки можем формировать. Но реально в линию dominant шлётся. Я уже к проводам TXCAN светодиоды припаял. Так он у приёмника в error passive mode, вроде светится не должен, а светится. А может я что-то не так понял с этим error passive?
С CERG:CRC Error General и FERG:Form Error General - вроде понятно. Думаю, что заставлю их установиться (пока просто этим не занимался).
Но бит AERG: Acknoweledgment Error General в том-же CANGIT упорно устанавливаться не хочет. Уж я, что только не делал. Но, думаю, раз есть такой бит - должен-же он когда-нибудь устанавливаться. Иначе - зачем его делать-то? Может кто-нибудь подскажет как заставить его установиться?

А как он может установиться? Он же может установиться только у передатчика а ошибки передачи устанавливаются в MOB.

Тогда, зачем-же его сделали-то??? Еррату изучал - ничего об этом нет.
Интересно, а как у других КАН контроллеров? Есть что-то подобное?
Я-то кроме AT90CAN128 пока ничего не пробовал. Да и вообще - токо 3-ю неделю КАНаю (в свободное от основной работы время).

Самый лучший с точки зрения диагностики IMHO SJA1000 от филипс (теперь NXP). Там вообще нет боксов (есть фифо на прием). Там из статуса можно узнать только текущее состояние типа error passive, bus off...
Но если обрабатывать прерывания (можно полингом) то есть регистры типа error code capture register из которого можно узнать полную информацию об ошибке включая направлние передачи и в каком месте с точностью до бита. Так же можно и об arbitration lost узнать...

Похожая схема и у LPC2000.

Подскажите, если возникает состояние Bus off, то как из него выйти? Только общим перезапуском микроконтроллера или существует другой способ?

когда возниает busoff CAN контроллер переходит в ресет моде (в котором можно конфигурировать BIT TIMING и т.д.) что бы возобновить работу его надо запустить заново ( так же как и при начале работы) только запуск будет длится дольше
Но CAN128 не входит в Standby mode (но на шину не выходит), а ждет 128 раз 11 recessive bits.(покрайней мере так на диаграмме нарисовано)
IMHO самое логичное в случае BUSOFF проресетить или весь контроллер или хотя бы CAN (там есть SWRES) и проинитить CAN заново и запустить

Не подскажет ли кто-нибудь, при каких условиях может возниктуть эта ошибка
SERR: Stuff error. Detection of more than five consecutive bit with the same polarity ?

Так ведь там написано. Больше 5 одинаковых бит подряд в пакете. Самый стандартный случай возникновения этой ошибки - это когда кто-то находясь в состоянии Error Active ошибку нашёл и пакет с ошибкой, выставив доминанту на 6 бит, разрушил. Это называется Error Frame кадр послал. Кроме того из-за неодинаковых скоростей у более быстрого это м.б. Ну и из-за помех в линии конечно.

а что это означает?

А то и означает, что пакет гарантированно испортил. Т.к. доминанта в течении 6 бит гарантированно будет воспринята ВСЕМИ девайсами как ошибка (stuff error). Реально другие девайсы, увидев эту ошибку (а вызвавшую нет), тоже выставят доминанту на 6 бит. Из-за этого может получится наложение доминант на 12 бит.
А вообще советую САМОМУ прочесть описание протокола CAN. Там это всё отлично описано.