Общие ошибки у AT90CAN128 - когда они должны возникать?, А ведь все когда-то чайниками были! Опции

[galjoen]

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

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

[KRS]

6. Отрубил у принимающего устройства TXCAN (не передаёт в линию ACK) - начались вопросы:
У принимающего устройства возникает ошибка "ACK error", хотя по описанию (да и логически) должна-бы возникнуть "Bit Error". Устройство-то передаёт в линию 0-й уровень (ACK), а в линии 1.

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

7. Запретил у принимающего устройства приём адреса генерируемого передатчиком. Судя по описанию в этом случае должна возникнуть общая ошибка - ACK error general (в линии имеется кадр с ресессивным уровнем в бите ACK). Реально у приёмника не возникает никаких ошибок. Пробовал запретить все MOb вообще, проверял разрешение всего, что относится к общим ошибкам - бесполезно.

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

[galjoen]

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

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

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

Я понимаю так:
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") не устанавливаются.
Из-за этого невозможно проанализировать шину, что я собирался сделать в отладочных целях.

[KRS]

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

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

Я понимаю так:
1. Контроллер принимает фрейм и проверяет проходит-ли он через фильтры.
2. Если проходит - кладёт его в MOb (MOb-ы), устанавливает в слоте ACK - dominant уровень

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

[galjoen]

А рвать линю TXCAN - не корректно вы просто отключаете физический уровень. И любая попытка отпрвить что то с этого узла приведет к Bus Off

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

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

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

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

[KRS]

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

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

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

Вот выдрежка из даташита на 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) можно посмотреть - все определно стандартом!

[galjoen]

Вот выдрежка из даташита на 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.
И логически - это ошибка физического уровня. А то что не в один ящик не попало это другой уровень уже.

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

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

[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.