Счетчики ошибок и прерываний CAN

Я использую периферийное устройство bxCAN на STMF3 uC в среде, где

1.) важно, чтобы узел был отключен от сети, как только REC / TEC достигнет уровня предупреждения (ожидание состояния отключения шины не является вариантом)

2.) скорость передачи хост-сети неизвестна

3.) соединение может быть спорадическим, так как узел подключается пользователем.

Из-за 1.) драйвер STM32 HAL CAN используется в режиме IT, и всякий раз, когда вызывается с установленным флагом EWG, обратный вызов ошибки завершает работу трансивера и деинициализирует bxCAN. Если значение REC превышает лимит, его легко восстановить, настроив bxCAN в тихом режиме, предполагая, что по CAN есть трафик. Однако, если TEC превышает лимит, bxCAN не сможет передать другой кадр, так как прерывание из-за ошибки будет немедленно инициировано после включения -> вот и мы в тупике.

Я попытался уменьшить TEC, передавая кадры в бесшумном режиме обратной связи, но, похоже, успешные передачи не влияют на TEC в этом режиме.

Я полагаю, что вопрос не относится к этому периферийному устройству, но действителен для других реализаций CAN.

Любые предложения приветствуются.


embedded can-bus microcontroller stm32 isr
person gyorig    schedule 20.07.2017    source источник
comment
Если TEC превышает лимит, вы будете отключены от шины, и его можно будет восстановить, увидев достаточно хорошего принимаемого трафика, а не путем передачи. Похоже, уникальность вашей проблемы может быть связана с попыткой имитировать отключение шины и восстановление после более низкого порога. Можете ли вы сделать аппаратный сброс всего блока CAN в MCU?   -  person Chris Stratton    schedule 24.07.2017
comment
Именно так @ChrisStratton. К сожалению, используемое периферийное устройство CAN имеет функцию безопасности, поэтому запрос общего сброса не влияет на счетчики ошибок. Я понимаю, что то, что я пытаюсь достичь, не совсем стандартное поведение, но важно, чтобы мой узел отказывался молча, а другие узлы не были проинформированы.   -  person gyorig    schedule 24.07.2017
comment
Похоже, что единственная необычная часть вашей проблемы - это нежелание ждать предела аппаратных ошибок и отключения шины, чтобы делать то, что в противном случае является обычным процессом восстановления. Можете ли вы при нижнем пороге перейти в режим обратной связи или в бесшумном режиме, как-то быстро вызвать достаточно ошибок, чтобы отключить его, а затем выполнить обычный процесс восстановления?   -  person Chris Stratton    schedule 24.07.2017
comment
Но, сделав шаг назад, как вы думаете, это поможет? Что делает отключение сети и быстрое восстановление, чтобы помочь кому-то еще? Почему бы просто не отступить в своей деятельности, если вы думаете, что причиной перегруженности является перегрузка, или не отключиться навсегда, если вы думаете, что вы сломались, и в противном случае позволить нормальным механизмам исцеления работать?   -  person Chris Stratton    schedule 24.07.2017
comment
попробуйте настроить режим только прослушивания / режим Limp Home, а затем измените режим, влияет ли это на счетчик?   -  person Sivaramakrishna Shriraam    schedule 02.08.2017
comment
@ChrisStratton быстро выздоравливает - это не главное, а вот уходить. Это диагностический инструмент, над которым я работаю, это больше, чем сниффер CAN, поскольку он должен адресовать несколько узлов на шине. В зависимости от фактической сети, к которой он подключен, могут быть узлы, которые реализуют такие строгие механизмы тайм-аута, что разрешение периферийному устройству CAN достичь состояния отключения шины перерастет в сигнал тревоги на более высоких уровнях. У меня есть обходной путь, я объясню это в ответ.   -  person gyorig    schedule 03.08.2017

Ответы (1)


arrow_upward
0
arrow_downward

Я реализовал обходной путь, который, кажется, работает нормально, со следующими требованиями:

1.) всякий раз, когда срабатывает ISR ошибки CAN, он отключает узел от шины (трансивер отключается)

2.) не все источники прерываний включены, только те, которые имеют более высокий уровень серьезности, чем последнее состояние ошибки (например, в состоянии ПАССИВНОЕ состояние прерывания ПРЕДУПРЕЖДЕНИЕ и ПАССИВНОЕ отключены, а прерывание BUSOFF разрешено)

3.) последнее состояние ошибки и, следовательно, источники прерываний обновляются всякий раз, когда: a.) Запускается ISR ошибки или b.) Опрос периферийного устройства CAN с высокой частотой показывает изменение состояния ошибки

4.) всякий раз, когда вы пытаетесь подключиться к шине, REC сначала должен восстановиться в режиме только прослушивания. Для этого в автобусе требуется движение транспорта.

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

person gyorig    schedule 03.08.2017