drnoob 0 20 февраля, 2015 Опубликовано 20 февраля, 2015 · Жалоба Ребята, помогите разобраться. В стандарте J1939 сказано, что если два узла с одинаковыми идентификаторами и разными данными осуществляют передачу одновременно, то произойдет коллизия. Коллизия приведет к ошибке, количество ошибок определит статус узла(активная ошибка, пассивная ошибка, отключение от шины). Но непонятно как отловить эту коллизию? По каким признакам определить, что произошла именно коллизия? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adnega 11 20 февраля, 2015 Опубликовано 20 февраля, 2015 · Жалоба По каким признакам определить, что произошла именно коллизия? А какой МК используется? Обычно в регистрах статуса указывается фаза, при которой ошибка возникла. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
drnoob 0 20 февраля, 2015 Опубликовано 20 февраля, 2015 · Жалоба Вот комбинации флагов состояния в зависимости о количества ошибок(контроллер 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 20 февраля, 2015 Опубликовано 20 февраля, 2015 · Жалоба Вот комбинации флагов состояния в зависимости о количества ошибок(контроллер 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 20 февраля, 2015 Опубликовано 20 февраля, 2015 · Жалоба Интересно, даже не знал. Жаль, подобной детализации нет во фрискейлах. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adnega 11 20 февраля, 2015 Опубликовано 20 февраля, 2015 · Жалоба Интересно, даже не знал. Жаль, подобной детализации нет во фрискейлах. В 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 6 мая, 2015 Опубликовано 6 мая, 2015 · Жалоба Вообще в CAN коллизия ошибкой не является и не ведет к порче данных. Передатчик, проигравший арбитраж, перестает передавать и ждет освобождения шины, после чего передает свое сообщение. Ошибкой может стать блокировка шины, когда на шине образуется доминанта, и передатчики не могут запустить передачу. Тогда формируются ошибки шины связи. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adnega 11 6 мая, 2015 Опубликовано 6 мая, 2015 · Жалоба Вообще в CAN коллизия ошибкой не является и не ведет к порче данных. Вы не путаете коллизию с потерей арбитража? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
lead_seller 0 6 мая, 2015 Опубликовано 6 мая, 2015 (изменено) · Жалоба Вы не путаете коллизию с потерей арбитража? А чем проигрыш арбитража отличается от коллизии в CAN? При учете того, что с шины уходит тот передатчик, который из-за коллизии не может установить передаваемое состояние. При это данные, передаваемые выигравшим передатчиком, не искажаются. Да, внимательно перечитал старт темы, вношу правку - я расписывал про коллизию и арбитраж на MAC уровне CAN. ТС же говорил о коллизии на уровне протокола, когда на шине будут работать два устройства с одинаковым адресом. Такую коллизию поймать средствами MAC-уровня невозможно, это должно решаться как раз на протокольном уровне. Изменено 6 мая, 2015 пользователем lead_seller Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adnega 11 6 мая, 2015 Опубликовано 6 мая, 2015 · Жалоба А чем проигрыш арбитража отличается от коллизии в CAN? Хоть это и не относится к вопросу ТС... давайте разберемся) Если адреса узлов разные и передача стартует одновременно, то узел с меньшим адресом выигрывает арбитраж и продолжает передавать. Проигравший не просто отвалится, он еще и корректно примет эту посылку. Но это только в поле адреса узла. Если при передаче данных и служебных полей будет обнаружен доминант при передаче рецессива, то узел не перейдет в режим слушателя, а начнет активно действовать: 1) увеличит счетчик ошибок передачи (+8?); 2) если счетчик меньше определенного значения (<127?), то выставит несколько доминантов (6?) на шине - мол, ошибка (активная). Все кто принимал увидят эту ошибку и увеличат свои счетчики ошибок приема; 3) если счетчик больше определенного числа, то выставит несколько рецессивов (6?) - тоже ошибка, только пассивная; 4) если счетчик переполнился (255), то наступает bus-off на сколько-то idle-циклов шины (13?). 5) если счетчик не переполнился, то будет повторная передача (если она включена, зависит от протокола, настроек контроллера и т.п.). При этом bus-off гарантируется. Итого: два одинаковых id узла на шине страшное зло! а не просто потеря арбитража. PS. В деталях могу напутать, но общий смысл такой. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
lead_seller 0 7 мая, 2015 Опубликовано 7 мая, 2015 · Жалоба Хоть это и не относится к вопросу ТС... давайте разберемся) Если адреса узлов разные и передача стартует одновременно, то узел с меньшим адресом выигрывает арбитраж и продолжает передавать. Проигравший не просто отвалится, он еще и корректно примет эту посылку. Но это только в поле адреса узла. Если при передаче данных и служебных полей будет обнаружен доминант при передаче рецессива, то узел не перейдет в режим слушателя, а начнет активно действовать: 1) увеличит счетчик ошибок передачи (+8?); 2) если счетчик меньше определенного значения (<127?), то выставит несколько доминантов (6?) на шине - мол, ошибка (активная). Все кто принимал увидят эту ошибку и увеличат свои счетчики ошибок приема; 3) если счетчик больше определенного числа, то выставит несколько рецессивов (6?) - тоже ошибка, только пассивная; 4) если счетчик переполнился (255), то наступает bus-off на сколько-то idle-циклов шины (13?). 5) если счетчик не переполнился, то будет повторная передача (если она включена, зависит от протокола, настроек контроллера и т.п.). При этом bus-off гарантируется. Итого: два одинаковых id узла на шине страшное зло! а не просто потеря арбитража. PS. В деталях могу напутать, но общий смысл такой. Спасибо за информацию. Действительно начал вчитываться в доступное, там расписывается алгоритм арбитража именно в Arbitration field. Не подскажите, где можно посмотреть именно по коллизиям вне поле арбитража? К сожалению доступа к ISO 11898 не имею, а общедоступные статьи описывают только арбитраж в поле заголовка пакета. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adnega 11 7 мая, 2015 Опубликовано 7 мая, 2015 · Жалоба Спасибо за информацию. Действительно начал вчитываться в доступное, там расписывается алгоритм арбитража именно в Arbitration field. Не подскажите, где можно посмотреть именно по коллизиям вне поле арбитража? К сожалению доступа к ISO 11898 не имею, а общедоступные статьи описывают только арбитраж в поле заголовка пакета. Вот тут есть статейки. Там же подробности. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться