dimka76 62 September 23 Posted September 23 · Report post Здравствуйте. Работаю с CAN на указанном выше микроконтроллере. Это фактически клон STM32. CAN настроен на режим Silent mode. В сети три устройства. Два работаю в нормальном режиме, а одно в Silent Mode. Одно устройство, работающее в нормальном режиме с некоторой периодичность отправляет один и тот же пакет. Настроен фильтр на определенный CAN ID После включения питания первые первые 16 пакетов не принимаются моим устройством, дальше прием работает нормально. И при каждом включении питания или сбросе все стабильно повторяется - первые 16 пакетов не принимаются. В чем может быть дело ? Quote Share this post Link to post Share on other sites More sharing options...
jcxz 240 September 23 Posted September 23 · Report post 27 минут назад, dimka76 сказал: После включения питания первые первые 16 пакетов не принимаются моим устройством, дальше прием работает нормально. И при каждом включении питания или сбросе все стабильно повторяется - первые 16 пакетов не принимаются. В чем может быть дело ? Может в процессе вкл.питания какая-то из сторон отправляет сбойные CAN-кадры? Счётчик ошибок CAN достигает максимума и на одном из участников CAN шина переходит в состояние bus-off. Которое позже где-то сбрасывается. Это как версия. Вобщем - я бы проверил состояние счётчиков ошибок во время этих самых "первых 16 пакетов". Quote Share this post Link to post Share on other sites More sharing options...
dimka76 62 September 23 Posted September 23 · Report post On 9/23/2024 at 4:21 PM, jcxz said: Может в процессе вкл.питания какая-то из сторон отправляет сбойные CAN-кадры? Счётчик ошибок CAN достигает максимума и на одном из участников CAN шина переходит в состояние bus-off. Второе устройство, которое настроено в нормальном режиме и ведет прием, принимает без пропусков. Первое и второе устройство в нормально режиме. Третье устройство (проблемное, про которое я тему поднял) в Silent. Первое только передает, остальные принимают. On 9/23/2024 at 4:21 PM, jcxz said: Вобщем - я бы проверил состояние счётчиков ошибок во время этих самых "первых 16 пакетов". Хорошо, попробую. Спасибо. ------------------------------------------------------------------------- На этот МК документа Errata нет. Я найти не смог. Quote Share this post Link to post Share on other sites More sharing options...
jcxz 240 September 23 Posted September 23 · Report post 28 минут назад, dimka76 сказал: Второе устройство, которое настроено в нормальном режиме и ведет прием, принимает без пропусков. Счётчики ошибок могут быть в МК. Локальные. Я не знаю CAN в STM32 (и тем паче - в китайцах), но в XMC4xxx в позапрошлом проекте у меня была похожая проблема: Из-за некорректной схемы подключения CAN-драйвера (чип) к МК (не было подтяжки цепей управления вроде), в моменты вкл. и выкл.питания устройства, этот драйвер впадал в ступор фиксировал на своих выходах доминантное состояние на ~0.6 сек. И на всех остальных участниках шины из-за этого в этот момент быстро инкрементировались счётчики ошибок. А реакция на достижение локальным счётчиком ошибок в МК некоего предела, может быть - не обязательно выставление на шину состояния ошибки. Состояние ошибки может быть выставлено локально, внутри данного конкретного МК. И он отключится от транзакций по шине. При этом - у других участников шины, счётчики ошибок могут и не достичь максимума, и они продолжат работу. И снаружи это будет выглядеть как: "все девайсы работают, а один почему-то не видит обмена по шине и сам туда ничего не выдаёт". А если ещё у вас в устройствах реализован периодический сброс этих счётчиков, то поведение разных девайсов может быть вообще очень сложным и труднопрогнозируемым. 28 минут назад, dimka76 сказал: На этот МК документа Errata нет. Я найти не смог. Не понял - причём тут errata? PS: да, кстати - отваливаться по накопленным ошибкам может не только ваш девайс, но и тот USB-CAN-свисток, которым мониторите обмен. (если вы конечно через USB-CAN мониторите). Quote Share this post Link to post Share on other sites More sharing options...
Arlleex 183 September 23 Posted September 23 · Report post 13 минут назад, jcxz сказал: Счётчики ошибок могут быть в МК. Локальные. Я не знаю CAN в STM32 (и тем паче - в китайцах), но в XMC4xxx в позапрошлом проекте у меня была похожая проблема: Из-за некорректной схемы подключения CAN-драйвера (чип) к МК (не было подтяжки цепей управления вроде), в моменты вкл. и выкл.питания устройства, этот драйвер фиксировал на своих выходах доминантное состояние на ~0.6 сек. Некоторые трансиверы имеют защиту TX DTO, например, SN65HVD1050, т.е. внутри схема сама отрубит TX внутри, если МК сойдет с ума и защелкнет TX в 0 на большое время. Это так, вспомнилось. Quote Share this post Link to post Share on other sites More sharing options...
adnega 11 September 23 Posted September 23 · Report post Ровно с такой же проблемой сейчас разбираюсь. Есть подозрение, что из-за цепей развязки узел-передатчик с запозданием получает ACK от узла-приемника. Quote Share this post Link to post Share on other sites More sharing options...
girts 9 September 23 Posted September 23 · Report post 1 hour ago, Arlleex said: Некоторые трансиверы имеют защиту TX DTO, например, SN65HVD1050, т.е. внутри схема сама отрубит TX внутри, если МК сойдет с ума и защелкнет TX в 0 на большое время. Это так, вспомнилось. Если девайс в silent mode, то хоть режь Tx... К делу отношения не имеет как бы никакого. 14 minutes ago, adnega said: Ровно с такой же проблемой сейчас разбираюсь. Есть подозрение, что из-за цепей развязки узел-передатчик с запозданием получает ACK от узла-приемника. Тонкая настройка всяких там propagation delay и подобного иногда спасает ситуацию. Если линейные размеры системы не вышли за пределов возможного (мегабит на 2 километра и прочие недочёты). По проблеме топикстартера - толкового ответа быть не может имхо, слишком много неизвестного. Да что угодно - пропущенное прерывание, которое не повторяется, где то лишний сброс флажков, обработка не того прерывания и тому подобное. 16 сообщений - все валидные? Если бить раз в секунду - принимать будет с задержкой в 16 секунд? Также - классика - пока слот занят (не разгружен), следующему мессагу приниматся негде. Поэтому, если там чисто что то бомбит неприлично, чтобы не пропустить сообщения иногда делают два слота на приём и обрабатывают поочерёдно. Ну а немедленная разгрузка в FIFO - это уже по классике. Quote Share this post Link to post Share on other sites More sharing options...
dimka76 62 September 23 Posted September 23 · Report post On 9/23/2024 at 5:03 PM, jcxz said: Не понял - причём тут errata? На всякий случай написал. Для справки. Вот схема для третьего устройства. Третье устройство в Silent Mode, т.е. вообще в сеть ничего не отправляет. Режим "шпиона". R5 не установлен. PB3 для пробуждения МК от CAN шины сделал. On 9/23/2024 at 6:24 PM, girts said: 16 сообщений - все валидные? Да, т.к. второе устройство подтверждает все сообщения. On 9/23/2024 at 6:24 PM, girts said: Если бить раз в секунду - принимать будет с задержкой в 16 секунд? Не задержка, а именно пропуск. Дальше все пакеты третьим устройством принимаются. Т.е., если первые 16 пакетов отправлял 10, а семнадцатым отправил 20, то и примется 20. Все три устройства лежат на столе. Провода 10-15 см длинной. Скорость передачи 500 кбит/с Quote Share this post Link to post Share on other sites More sharing options...
dimka76 62 September 23 Posted September 23 · Report post 4 hours ago, jcxz said: А если ещё у вас в устройствах реализован периодический сброс этих счётчиков, то поведение разных девайсов может быть вообще очень сложным и труднопрогнозируемым. Счетчики в этом МК программно сбросить нельзя. В этом регистре вообще все биты только для чтения. Quote Share this post Link to post Share on other sites More sharing options...
adnega 11 September 23 Posted September 23 · Report post Чему равны счетчики ошибок? Где установлена точка сэмплирования? Quote Share this post Link to post Share on other sites More sharing options...
jcxz 240 September 23 Posted September 23 · Report post 1 час назад, dimka76 сказал: В этом регистре вообще все биты только для чтения. Так может у вас REC или TEC достигает 127 и временно входит в это самое "error passive state"? Если попробовать помониторить их в каком-то периодическом (таймерном) прерывании? и поискать максимальные значения? Quote Share this post Link to post Share on other sites More sharing options...
dimka76 62 September 23 Posted September 23 · Report post On 9/23/2024 at 11:07 PM, jcxz said: Так может у вас REC или TEC достигает 127 и временно входит в это самое "error passive state"? Если попробовать помониторить их в каком-то периодическом (таймерном) прерывании? и поискать максимальные значения? Да, попробую обязательно. Только вот второе устройство же принимает без ошибок. On 9/23/2024 at 10:25 PM, adnega said: Чему равны счетчики ошибок? Пока еще не успел посмотреть. On 9/23/2024 at 10:25 PM, adnega said: Где установлена точка сэмплирования? CAN1->BTIMR = (0UL << CAN_BTIMR_SJW_Pos) | // 1 TQ (3UL << CAN_BTIMR_TS1_Pos) | // 4 TQ (2UL << CAN_BTIMR_TS2_Pos) | // 3 TQ (11UL << CAN_BTIMR_BRP_Pos) | (1UL << CAN_BTIMR_SILM_Pos); // Silent mode Quote Share this post Link to post Share on other sites More sharing options...
adnega 11 September 23 Posted September 23 · Report post Попробуйте SJW=1, TS1=6, TS2=1 - будут рекомендованные 87.5% Quote Share this post Link to post Share on other sites More sharing options...
girts 9 September 23 Posted September 23 · Report post 7 hours ago, dimka76 said: Настроен фильтр на определенный CAN ID После включения питания первые первые 16 пакетов не принимаются моим устройством, дальше прием работает нормально. И при каждом включении питания или сбросе все стабильно повторяется - первые 16 пакетов не принимаются. 1 hour ago, dimka76 said: Не задержка, а именно пропуск. Дальше все пакеты третьим устройством принимаются. Т.е., если первые 16 пакетов отправлял 10, а семнадцатым отправил 20, то и примется 20. Не понятно. Именно 16, а не 15 или 17..... Не смущает? Выложил бы как там маски фильтры у вас задаются, и кусочек лога... Чего гадать то... Quote Share this post Link to post Share on other sites More sharing options...
dimka76 62 September 30 Posted September 30 · Report post Блин. Как всегда дело было не в бобине CAN пропускал пакеты не при включении платы, а после выхода МК из SLEEP. Да и не самом деле сам CAN ничего не пропускал. Пропускал мой алгоритм. Сразу после выхода из SLEEP у меня запускалась блокирующая функция. Из-за этого алгоритм просто не мог получать пакеты от CAN. Сами прерывания на входящие CAN пакеты срабатывали. Переделал ту злосчастную блокирующую функцию на неблокирующую и все наладилось. Всем спасибо за участие !!! Quote Share this post Link to post Share on other sites More sharing options...
