[Arlleex 131]

30 минут назад, jcxz сказал:

И тогда было бы яснее где искать баг.

Сниффер и любые абоненты (в режиме смотрителя) показывали именно "подмену ID", т.е. сообщение с каким-то ID передавалось с содержимым, предназначенным для сообщения с другим ID. То есть, условно передатчик выполняет код

test()
{
  can_Send(0x1, 0x1234); // ID = 0x1, DATA = 0x1234
  can_Send(0x2, 0x5678); // ID = 0x2, DATA = 0x5678
}

а приемниками редко (и если шурудить кабельную часть) ловится 0x5678 в сообщении с ID 0x1 (или наоборот, 0x1234 в сообщении с ID 0x2).

 

ID 0x1/0x2 чисто для примера, в реальности там были адекватные и радикально отличающиеся по битам ID, коих сейчас не вспомню, дело было еще в августе 2019...

[jcxz 184]

10 часов назад, Arlleex сказал:

а приемниками редко (и если шурудить кабельную часть) ловится 0x5678 в сообщении с ID 0x1 (или наоборот, 0x1234 в сообщении с ID 0x2).

А если выставлять несколько майлбоксов на передачу с разными ID одновременно (атомарно), то они отправляются в правильном порядке (по приоритету)?

Т.е. - не содержимое, а отправляемые ID идут по нарастанию номеров?

И были ли на шине какие-то репитеры (удлинители линии)?

[Arlleex 131]

В 06.03.2020 в 09:12, jcxz сказал:

А если выставлять несколько майлбоксов на передачу с разными ID одновременно...

А это как?

Ведь процессор заполняет их все-равно по очереди, и если сейчас передачи нет, он начнет передавать первый заполненный мэйлбокс.

Ну и все-таки, при загруженной обменами шине, при возникновении такой ситуации (а это будет часто), что два мэйлбокса будут заполнены и ожидать отправки, отправляться они будут в правильном порядке согласно ID.

 

В 06.03.2020 в 09:12, jcxz сказал:

И были ли на шине какие-то репитеры (удлинители линии)?

Нет, эксперимента ради отсекли все промежуточные и ненужные компоненты из системы.

В итоге, остался только блок на ATSAMA5D и CAN-анализатор.

[jcxz 184]

3 часа назад, Arlleex сказал:

А это как?

Ведь процессор заполняет их все-равно по очереди, и если сейчас передачи нет, он начнет передавать первый заполненный мэйлбокс.

В зависимости от возможностей конкретного МК. Я не знаю как работает CAN-периферия в вашем МК, поэтому не могу конкретно ответить на этот вопрос.

Например в XMC4xxx есть бит "Transmit Disable" для всего CAN-узла: выставить его, заполнить несколько message object-ов данными, снять бит "Transmit Disable".

 

Цитата

Ну и все-таки, при загруженной обменами шине, при возникновении такой ситуации (а это будет часто), что два мэйлбокса будут заполнены и ожидать отправки, отправляться они будут в правильном порядке согласно ID.

Я говорю о том, что возможно есть какие-то проблемы в работе схемы арбитража. А у Вас когда это происходило, сообщения c ID 0x1 и ID 0x2 в описанном случае отправлялись с одного CAN-узла (одного МК) или с разных?

В 05.03.2020 в 22:44, Arlleex сказал:

Грубо говоря, отправляю 0x1234 в сообщении с ID 0x1 и 0x5678 в сообщении с ID 0x2.

На приеме при ловле глюка получаю, например, в сообщении с ID 0x1 данные 0x5678.

Эта отправка делалась с одного CAN-узла или с разных?

[Arlleex 131]

1 час назад, jcxz сказал:

Эта отправка делалась с одного CAN-узла или с разных?

Кратко: с одного.

 

Не кратко...

На той шине, насколько помню, изначально (в штатной системе) висело несколько десятков узлов.

Проблема проявлялась, падла, раз в неделю а то и реже. И не пойми при каких обстоятельствах.

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

А в CAN не так просто сходу определить, какой блок выплюнул CAN-фрейм с (даже) известным идентификатором.

Буквально на коленке делали многопортовые CAN-анализаторы с возможностью "врезаться" в разрыв нужного блока, чтобы видеть трафик к нему и от него.

Благо подозрения на оборудование мировых брендов у меня сразу отпадали (ну или сразу отходили на последний пункт). Волей неволей дошли до подозреваемого.

Но он, гаденыш, работает, не докопаться. И на загрузках шины сверх нормы вплоть до 100%. Не ломается и все тут. Сделали имитацию хренового контакта в соединителях CAN. Стали тестить и на тебе - через пару минут уже в "самодельной" программе CAN-хакера (да и штатный то же самое показывал, только неудобно уже было им пользоваться) вылезли триггеры, что сообщения приходят не с теми идентификаторами. Ну супер, че. Поймали. Радости полные штаны

Ну а дальше еще пару дней на разные тесты, где, в конце концов, выяснили, что даже такой простой тест (код приводил уже примерный) отправляет не те сообщения при большом количестве трабблов на физической шине. Отправляет, допустим, пару тысяч правильных сообщений, и тут на тебе, одно с "подмененными" ID. Сейчас уже не вспомню точной конкретики, но даже были ситуации, когда отправляя сообщения, например, A, B, C (в порядке увеличения ID), я видел, что, допустим, B не отправилось вообще, а в C лежат данные для сообщения B. A дошло нормально. А ведь тест простейший и сообщения задавались статично, чтобы их можно было отличать друг от друга.

В общем, стали копать даташит. Искурили вдоль и поперек весь раздел по CAN и даже раздел с настройкой клоков и прочей атрибутики прошерстили. Все должно работать.

В итоге, написали с нуля свои функции отправки и приема. С прерываниями и на поллинге, результат тот же. Еще больше облегчили условия, сделав передающим только один из доступных 8 (вроде) мэйлбоксов. И все заработало. Ошибок больше не было. Причем, для того, чтобы поймать ошибку, можно было пошурудить соединительные провода, и через минутку оно вылезет, но я пошел еще дальше. Сделали релюху, и с разными частотами рвали линию. День гоняли, два гоняли, три гоняли. Все ок. На этом и остановились.

Я сделал вывод, что это аппаратная косячелла. На тех примитивных тестах оно ни коим образом не должно было себя так вести.

Да и подумать: чтобы CAN-узел правильно принял данные, у него как минимум CRC кадра должна сойтись. А значит отправитель (тот сбойный блок) целенаправленно собирал так кадр. Только не в коде, а в аппаратном блоке CAN. И никакими дребезгами от релюхи это объяснить было нельзя - 100% повторяемость. Шо там под капотом в том ATSAMA5D, только микрочиповским студентам известно.

[jcxz 184]

20 часов назад, Arlleex сказал:

Сейчас уже не вспомню точной конкретики, но даже были ситуации, когда отправляя сообщения, например, A, B, C (в порядке увеличения ID), я видел, что, допустим, B не отправилось вообще, а в C лежат данные для сообщения B. A дошло нормально.

Т.е., как я понял так?:

A - отправилось нормально (в исходящем mailbox-е статус "отправлено" && в логе сниффера оно есть && приёмный узел его получил);

B - не отправилось (в исходящем mailbox-е статус "не отправлено" && в логе сниффера его нет && приёмный узел его не получил); А содержимое mailbox-а (неотправленного) правильное, какое записывали? Или исказилось?

C - не отправилось (в исходящем mailbox-е статус "не отправлено" && в логе сниффера его нет && приёмный узел его не получил); И содержимое mailbox-а неправильное, не соответствует записанному изначально в этот mailbox? А CRC какая? От исходного записанного содержимого или пересчитанная для нового ID + данные от B? Да и прочее содержимое (control field + длина) - от какого, B или C?

[Arlleex 131]

1 час назад, jcxz сказал:

A - отправилось нормально (в исходящем mailbox-е статус "отправлено" && в логе сниффера оно есть && приёмный узел его получил);

Да.

 

1 час назад, jcxz сказал:

B - не отправилось (в исходящем mailbox-е статус "не отправлено" && в логе сниффера его нет && приёмный узел его не получил); А содержимое mailbox-а (неотправленного) правильное, какое записывали? Или исказилось?

Да. При readback регистров данных - там лежат правильные данные. Не искаженные.

 

1 час назад, jcxz сказал:

C - не отправилось (в исходящем mailbox-е статус "не отправлено" && в логе сниффера его нет && приёмный узел его не получил); И содержимое mailbox-а неправильное, не соответствует записанному изначально в этот mailbox? А CRC какая? От исходного записанного содержимого или пересчитанная для нового ID + данные от B? Да и прочее содержимое (control field + длина) - от какого, B или C?

Нет. В статусе мэйлбокса сообщение C отправлено. В логе сниффера оно есть, приемный узел его получил. Содержимое при readback регистров данных соответствует сообщению C, но приемник получил его с данными для сообщения B. Все параметры я на память не скажу чему равны, но помню, что длина и данные получены именно как бы для сообщения B. Но ID сообщения соответствует сообщению C. То есть как будто механизм выдачи сообщений из очереди (при куче ошибок на шине) потерял голову и перед отправкой C копирнул из не отправленного мэйлбокса данные для B, рассчитал для итогового кадра контрольную сумму и пульнул в сеть. В итоге я анализатором (и/или приемником данных) увидел, что пришло сообщение с ID сообщения C, но в нем лежат данные для сообщения B. И их там никак появиться программно не может, это разные мейлбоксы в отправителе, я даже в мэйлбокс для сообщения C явно или косвенно данные для B не пишу.

Я даже больше еще скажу: как помню, я заполнял регистры данных и параметров (длина, ID) единожды. То есть в цикле отправки у меня всего лишь взводились биты "отправить".

В итоге: readback этих регистров всегда выдает правильный результат (что писали изначально, то там и лежит). А ошибка все равно проявляется.

ИМХО, в CAN-блоке же еще до кучи аппаратных очередей сделано, так что то, что записано в мэйлбоксе - это теневые данные, а до непосредственно передатчика данным из этих регистров предстоит еще доехать. И вот именно в этом, неведомом мне (по крайней мере) месте что-то пошло не так...