Общие ошибки у 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]

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

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

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

[galjoen]

Может Вы про то что в реализации CAN128 есть регистры MOB а есть General.

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

- The identified has not or not yet matched:
The error is set at general level.

Эту выдержку из даташита я понял так: если, или пока ещё, индентификатор не соответствует (ни одному из установленных в принимающих 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 упорно устанавливаться не хочет. Уж я, что только не делал. Но, думаю, раз есть такой бит - должен-же он когда-нибудь устанавливаться. Иначе - зачем его делать-то? Может кто-нибудь подскажет как заставить его установиться?

[KRS]

Но бит AERG: Acknoweledgment Error General в том-же CANGIT упорно устанавливаться не хочет. Уж я, что только не делал.

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

[galjoen]

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

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

[KRS]

Интересно, а как у других КАН контроллеров?

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

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

[KSN]

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

[KRS]

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

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

Сообщение отредактировал KRS - Mar 5 2008, 19:15