[drnoob 0]

Ребята, помогите разобраться.

В стандарте J1939 сказано, что если два узла с одинаковыми идентификаторами и разными данными осуществляют передачу одновременно, то произойдет коллизия. Коллизия приведет к ошибке, количество ошибок определит статус узла(активная ошибка, пассивная ошибка, отключение от шины). Но непонятно как отловить эту коллизию? По каким признакам определить, что произошла именно коллизия?

[adnega 11]

По каким признакам определить, что произошла именно коллизия?

А какой МК используется?

Обычно в регистрах статуса указывается фаза, при которой ошибка возникла.

[drnoob 0]

Вот комбинации флагов состояния в зависимости о количества ошибок(контроллер mc9s08dz32):

 

00 TxOK: 0≤transmit error counter ≤96

01 TxWRN: 96<transmit error counter≤127

10 TxERR: 127<transmit error counter≤255

11 Bus-Off: transmit error counter>255

 

Других условий, к сожалению, не нашел.

[adnega 11]

Вот комбинации флагов состояния в зависимости о количества ошибок(контроллер mc9s08dz32):

Это, скажем так, интегральная характеристика передачи (статистика передач за последнее время).

Бывает статус в пределах последней транзакции на шине.

У STM:

Bits 6:4 LEC[2:0]: Last error code

This field is set by hardware and holds a code which indicates the error condition of the last

error detected on the CAN bus. If a message has been transferred (reception or

transmission) without error, this field will be cleared to ‘0’.

The LEC[2:0] bits can be set to value 0b111 by software. They are updated by hardware to

indicate the current communication status.

000: No Error

001: Stuff Error

010: Form Error

011: Acknowledgment Error

100: Bit recessive Error

101: Bit dominant Error

110: CRC Error

111: Set by software

 

У NXP:

2:0 LEC Last error code

Type of the last error to occur on the CAN bus.The LEC field holds a

code which indicates the type of the last error to occur on the CAN bus.

This field will be cleared to ‘0’ when a message has been transferred

(reception or transmission) without error. The unused code ‘111’ may be

written by the CPU to check for updates.

000 R/W

0x0 No error.

0x1 Stuff error. More than 5 equal bits in a sequence have occurred in a

part of a received message where this is not allowed.

0x2 Form error. A fixed format part of a received frame has the wrong

format.

0x3 AckError. The message this CAN core transmitted was not

acknowledged.

0x4 Bit1Error. During the transmission of a message (with the exception of

the arbitration field), the device wanted to send a HIGH/recessive level

(bit of logical value ‘1’), but the monitored bus value was

LOW/dominant.

0x5 Bit0Error. During the transmission of a message (or acknowledge bit,

or active error flag, or overload flag), the device wanted to send a

LOW/dominant level (data or identifier bit logical value ‘0’), but the

monitored Bus value was HIGH/recessive. During busoff recovery this

status is set each time a sequence of 11 HIGH/recessive bits has been

monitored. This enables the CPU to monitor the proceeding of the

busoff recovery sequence (indicating the bus is not stuck at

LOW/dominant or continuously disturbed).

0x6 CRCError. The CRC checksum was incorrect in the message received.

0x7 Unused. No CAN bus event was detected (written by the CPU).

[drnoob 0]

Интересно, даже не знал. Жаль, подобной детализации нет во фрискейлах.

[adnega 11]

Интересно, даже не знал. Жаль, подобной детализации нет во фрискейлах.

В LPC2368 было еще подробнее)

20:16 ERRBIT

4:0[3]

Error Code Capture: when the CAN controller detects

a bus error, the location of the error within the frame is

captured in this field. The value reflects an internal

state variable, and as a result is not very linear:

0 X

00011 Start of Frame

00010 ID28 ... ID21

00110 ID20 ... ID18

00100 SRTR Bit

00101 IDE bit

00111 ID17 ... 13

01111 ID12 ... ID5

01110 ID4 ... ID0

01100 RTR Bit

01101 Reserved Bit 1

01001 Reserved Bit 0

01011 Data Length Code

01010 Data Field

01000 CRC Sequence

11000 CRC Delimiter

11001 Acknowledge Slot

11011 Acknowledge Delimiter

11010 End of Frame

10010 Intermission

10001 Active Error Flag

10110 Passive Error Flag

10011 Tolerate Dominant Bits

10111 Error Delimiter

11100 Overload flag

21 ERRDIR When the CAN controller detects a bus error, the

direction of the current bit is captured in this bit.

0 X

0 Error occurred during transmitting.

1 Error occurred during receiving.

23:22 ERRC1:0 When the CAN controller detects a bus error, the type

of error is captured in this field:

0 X

00 Bit error

01 Form error

10 Stuff error

11 Other error

 

Тут есть спецы по фрискейлам. Подождите - может подскажут.

[lead_seller 0]

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

Ошибкой может стать блокировка шины, когда на шине образуется доминанта, и передатчики не могут запустить передачу. Тогда формируются ошибки шины связи.

[adnega 11]

Вообще в CAN коллизия ошибкой не является и не ведет к порче данных.

Вы не путаете коллизию с потерей арбитража?

[lead_seller 0]

Вы не путаете коллизию с потерей арбитража?

 

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

 

Да, внимательно перечитал старт темы, вношу правку - я расписывал про коллизию и арбитраж на MAC уровне CAN.

ТС же говорил о коллизии на уровне протокола, когда на шине будут работать два устройства с одинаковым адресом. Такую коллизию поймать средствами MAC-уровня невозможно, это должно решаться как раз на протокольном уровне.

Изменено 6 мая, 2015 пользователем lead_seller

[adnega 11]

А чем проигрыш арбитража отличается от коллизии в CAN?

Хоть это и не относится к вопросу ТС... давайте разберемся)

 

Если адреса узлов разные и передача стартует одновременно, то узел с меньшим адресом выигрывает арбитраж и продолжает передавать.

Проигравший не просто отвалится, он еще и корректно примет эту посылку.

 

Но это только в поле адреса узла. Если при передаче данных и служебных полей будет обнаружен доминант при передаче рецессива, то

узел не перейдет в режим слушателя, а начнет активно действовать:

1) увеличит счетчик ошибок передачи (+8?);

2) если счетчик меньше определенного значения (<127?), то выставит несколько доминантов (6?) на шине - мол, ошибка (активная). Все кто принимал увидят эту ошибку и увеличат свои счетчики ошибок приема;

3) если счетчик больше определенного числа, то выставит несколько рецессивов (6?) - тоже ошибка, только пассивная;

4) если счетчик переполнился (255), то наступает bus-off на сколько-то idle-циклов шины (13?).

5) если счетчик не переполнился, то будет повторная передача (если она включена, зависит от протокола, настроек контроллера и т.п.). При этом bus-off гарантируется.

 

Итого: два одинаковых id узла на шине страшное зло! а не просто потеря арбитража.

 

PS. В деталях могу напутать, но общий смысл такой.

[lead_seller 0]

Хоть это и не относится к вопросу ТС... давайте разберемся)

 

Если адреса узлов разные и передача стартует одновременно, то узел с меньшим адресом выигрывает арбитраж и продолжает передавать.

Проигравший не просто отвалится, он еще и корректно примет эту посылку.

 

Но это только в поле адреса узла. Если при передаче данных и служебных полей будет обнаружен доминант при передаче рецессива, то

узел не перейдет в режим слушателя, а начнет активно действовать:

1) увеличит счетчик ошибок передачи (+8?);

2) если счетчик меньше определенного значения (<127?), то выставит несколько доминантов (6?) на шине - мол, ошибка (активная). Все кто принимал увидят эту ошибку и увеличат свои счетчики ошибок приема;

3) если счетчик больше определенного числа, то выставит несколько рецессивов (6?) - тоже ошибка, только пассивная;

4) если счетчик переполнился (255), то наступает bus-off на сколько-то idle-циклов шины (13?).

5) если счетчик не переполнился, то будет повторная передача (если она включена, зависит от протокола, настроек контроллера и т.п.). При этом bus-off гарантируется.

 

Итого: два одинаковых id узла на шине страшное зло! а не просто потеря арбитража.

 

PS. В деталях могу напутать, но общий смысл такой.

 

Спасибо за информацию. Действительно начал вчитываться в доступное, там расписывается алгоритм арбитража именно в Arbitration field. Не подскажите, где можно посмотреть именно по коллизиям вне поле арбитража? К сожалению доступа к ISO 11898 не имею, а общедоступные статьи описывают только арбитраж в поле заголовка пакета.

 

[adnega 11]

Спасибо за информацию. Действительно начал вчитываться в доступное, там расписывается алгоритм арбитража именно в Arbitration field. Не подскажите, где можно посмотреть именно по коллизиям вне поле арбитража? К сожалению доступа к ISO 11898 не имею, а общедоступные статьи описывают только арбитраж в поле заголовка пакета.

Вот тут есть статейки. Там же подробности.