dimka76 64 23 сентября Опубликовано 23 сентября · Жалоба Здравствуйте. Работаю с CAN на указанном выше микроконтроллере. Это фактически клон STM32. CAN настроен на режим Silent mode. В сети три устройства. Два работаю в нормальном режиме, а одно в Silent Mode. Одно устройство, работающее в нормальном режиме с некоторой периодичность отправляет один и тот же пакет. Настроен фильтр на определенный CAN ID После включения питания первые первые 16 пакетов не принимаются моим устройством, дальше прием работает нормально. И при каждом включении питания или сбросе все стабильно повторяется - первые 16 пакетов не принимаются. В чем может быть дело ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 251 23 сентября Опубликовано 23 сентября · Жалоба 27 минут назад, dimka76 сказал: После включения питания первые первые 16 пакетов не принимаются моим устройством, дальше прием работает нормально. И при каждом включении питания или сбросе все стабильно повторяется - первые 16 пакетов не принимаются. В чем может быть дело ? Может в процессе вкл.питания какая-то из сторон отправляет сбойные CAN-кадры? Счётчик ошибок CAN достигает максимума и на одном из участников CAN шина переходит в состояние bus-off. Которое позже где-то сбрасывается. Это как версия. Вобщем - я бы проверил состояние счётчиков ошибок во время этих самых "первых 16 пакетов". Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dimka76 64 23 сентября Опубликовано 23 сентября · Жалоба 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 нет. Я найти не смог. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 251 23 сентября Опубликовано 23 сентября · Жалоба 28 минут назад, dimka76 сказал: Второе устройство, которое настроено в нормальном режиме и ведет прием, принимает без пропусков. Счётчики ошибок могут быть в МК. Локальные. Я не знаю CAN в STM32 (и тем паче - в китайцах), но в XMC4xxx в позапрошлом проекте у меня была похожая проблема: Из-за некорректной схемы подключения CAN-драйвера (чип) к МК (не было подтяжки цепей управления вроде), в моменты вкл. и выкл.питания устройства, этот драйвер впадал в ступор фиксировал на своих выходах доминантное состояние на ~0.6 сек. И на всех остальных участниках шины из-за этого в этот момент быстро инкрементировались счётчики ошибок. А реакция на достижение локальным счётчиком ошибок в МК некоего предела, может быть - не обязательно выставление на шину состояния ошибки. Состояние ошибки может быть выставлено локально, внутри данного конкретного МК. И он отключится от транзакций по шине. При этом - у других участников шины, счётчики ошибок могут и не достичь максимума, и они продолжат работу. И снаружи это будет выглядеть как: "все девайсы работают, а один почему-то не видит обмена по шине и сам туда ничего не выдаёт". А если ещё у вас в устройствах реализован периодический сброс этих счётчиков, то поведение разных девайсов может быть вообще очень сложным и труднопрогнозируемым. 28 минут назад, dimka76 сказал: На этот МК документа Errata нет. Я найти не смог. Не понял - причём тут errata? PS: да, кстати - отваливаться по накопленным ошибкам может не только ваш девайс, но и тот USB-CAN-свисток, которым мониторите обмен. (если вы конечно через USB-CAN мониторите). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 209 23 сентября Опубликовано 23 сентября · Жалоба 13 минут назад, jcxz сказал: Счётчики ошибок могут быть в МК. Локальные. Я не знаю CAN в STM32 (и тем паче - в китайцах), но в XMC4xxx в позапрошлом проекте у меня была похожая проблема: Из-за некорректной схемы подключения CAN-драйвера (чип) к МК (не было подтяжки цепей управления вроде), в моменты вкл. и выкл.питания устройства, этот драйвер фиксировал на своих выходах доминантное состояние на ~0.6 сек. Некоторые трансиверы имеют защиту TX DTO, например, SN65HVD1050, т.е. внутри схема сама отрубит TX внутри, если МК сойдет с ума и защелкнет TX в 0 на большое время. Это так, вспомнилось. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adnega 11 23 сентября Опубликовано 23 сентября · Жалоба Ровно с такой же проблемой сейчас разбираюсь. Есть подозрение, что из-за цепей развязки узел-передатчик с запозданием получает ACK от узла-приемника. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
girts 9 23 сентября Опубликовано 23 сентября · Жалоба 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 - это уже по классике. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dimka76 64 23 сентября Опубликовано 23 сентября · Жалоба 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 кбит/с Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dimka76 64 23 сентября Опубликовано 23 сентября · Жалоба 4 hours ago, jcxz said: А если ещё у вас в устройствах реализован периодический сброс этих счётчиков, то поведение разных девайсов может быть вообще очень сложным и труднопрогнозируемым. Счетчики в этом МК программно сбросить нельзя. В этом регистре вообще все биты только для чтения. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adnega 11 23 сентября Опубликовано 23 сентября · Жалоба Чему равны счетчики ошибок? Где установлена точка сэмплирования? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 251 23 сентября Опубликовано 23 сентября · Жалоба 1 час назад, dimka76 сказал: В этом регистре вообще все биты только для чтения. Так может у вас REC или TEC достигает 127 и временно входит в это самое "error passive state"? Если попробовать помониторить их в каком-то периодическом (таймерном) прерывании? и поискать максимальные значения? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dimka76 64 23 сентября Опубликовано 23 сентября · Жалоба 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 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adnega 11 23 сентября Опубликовано 23 сентября · Жалоба Попробуйте SJW=1, TS1=6, TS2=1 - будут рекомендованные 87.5% Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
girts 9 23 сентября Опубликовано 23 сентября · Жалоба 7 hours ago, dimka76 said: Настроен фильтр на определенный CAN ID После включения питания первые первые 16 пакетов не принимаются моим устройством, дальше прием работает нормально. И при каждом включении питания или сбросе все стабильно повторяется - первые 16 пакетов не принимаются. 1 hour ago, dimka76 said: Не задержка, а именно пропуск. Дальше все пакеты третьим устройством принимаются. Т.е., если первые 16 пакетов отправлял 10, а семнадцатым отправил 20, то и примется 20. Не понятно. Именно 16, а не 15 или 17..... Не смущает? Выложил бы как там маски фильтры у вас задаются, и кусочек лога... Чего гадать то... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dimka76 64 30 сентября Опубликовано 30 сентября · Жалоба Блин. Как всегда дело было не в бобине CAN пропускал пакеты не при включении платы, а после выхода МК из SLEEP. Да и не самом деле сам CAN ничего не пропускал. Пропускал мой алгоритм. Сразу после выхода из SLEEP у меня запускалась блокирующая функция. Из-за этого алгоритм просто не мог получать пакеты от CAN. Сами прерывания на входящие CAN пакеты срабатывали. Переделал ту злосчастную блокирующую функцию на неблокирующую и все наладилось. Всем спасибо за участие !!! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
