[Polaris 0]

Занимаюсь реализацией самописного протокола для CAN на ATSAMC21, в целом все понятно и четко, скорость работы - 500 кбит/с. Для отладки и управления со стороны компьютера использую CAN-USB адаптер от Kvaser. Вроде бы все работало, начал смотреть, что там происходит на шине и обнаружил достаточно большое количество Error frames. Причем обнаруживаются они только в том случае, когда на шине более одного участника. Если к адптеру подключена одна плата - все хорошо, подключаешь вторую - до одного процента пакетов испорчены. Выглядит это вот так:

Зеленый канал - это состояние питания микроконтроллера, желтый - сама шина.

Второй участник при этом совершенно точно ничего не передает, я специально становился в отладке на функцию передачи - она ни разу не вызывалась. Кабель достаточно короткий, с обеих сторон терминирован 120 Ом.

Как видно из скриншотов, выброс связан с искажение бита ACK, но кто это может делать - я совершенно не понимаю. Фильтры на участниках настраивал и таким образом, чтобы отбрасывать чужие пакеты, ничего не дало, в принципе, и не должно было дать, это же ACK.

 

Что бы это могло быть?

[геннадий75 1]

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

[Edit2007 3]

Фильтры однозначно не причем. Возможно, на двух платах есть разница в скорости. CAN для сбоя достаточно бывает 1% расхождения. Тем более, если с одним устройством нормальный обмен.

Вариант найти виновника - контроль за счетчиками ошибок. Очевидно, что у одной платы это будут ошибки передачи, у другой ошибки приема.

Если бит ошибки формирует Kvaser - я бы однозначно смотрел в сторону подстройки скорости (железка за 500 евро у меня вызывает больше доверия, чем отлаживаемое ПО).

Можно для чистоты эксперимента и Kvaser в Silent Mode перевести(исключить формирование бита ошибки с его стороны).

[esaulenka 5]

On 12/13/2019 at 8:09 PM, Polaris said:

Как видно из скриншотов, выброс связан с искажение бита ACK

Я правильно понимаю, что величина этого выброса - заметно больше 5 вольт? Проверьте ещё разик, что земли у всех участников соединены.

 

On 12/13/2019 at 8:09 PM, Polaris said:

но кто это может делать

Попробуйте ткнуть осциллографом в TXD между контроллером и трансивером.

[Polaris 0]

6 hours ago, esaulenka said:

Я правильно понимаю, что величина этого выброса - заметно больше 5 вольт? Проверьте ещё разик, что земли у всех участников соединены.

 

Попробуйте ткнуть осциллографом в TXD между контроллером и трансивером.

Да, с землей есть такое, но суть оказалась не в этом. Проблема была в слишком большом разбросе частот у висящих на шине устройств, для такой скорости в ATSAMC21 нельзя использовать PLL, у него точность оказалась даже ниже, чем у внутреннего генератора, когда запитал ядро от внутреннего, а CAN от внешнего кварца без всякого умножителя, проблема исчезла начисто.

Но все равно спасибо за идею!

[esaulenka 5]

43 minutes ago, Polaris said:

в ATSAMC21 нельзя использовать PLL

Мда. Пока не наступишь на эти грабли, и не догадаешься...

А проблема документирована, на самом деле: http://ww1.microchip.com/downloads/en/DeviceDoc/80000740D.pdf 
"The FDPLL96M exhibits high period jitter and is not suitable for accurate clocking."

В новых ревизиях поправлено.

 

Но насколько этот PLL inaccurate, ни атмел, ни микрочип не сознались...

[Polaris 0]

17 hours ago, esaulenka said:

Мда. Пока не наступишь на эти грабли, и не догадаешься...

А проблема документирована, на самом деле: http://ww1.microchip.com/downloads/en/DeviceDoc/80000740D.pdf 
"The FDPLL96M exhibits high period jitter and is not suitable for accurate clocking."

В новых ревизиях поправлено.

 

Но насколько этот PLL inaccurate, ни атмел, ни микрочип не сознались...

Да, интересный факт, я там даже не искал, смотрел исключительно главу про CAN. Но на самом деле у меня ревизия E, так что, думаю, поправили не слишком хорошо. Но с их качеством документации оно и неудивительно.

[Vasily_ 41]

В 16.12.2019 в 17:24, Polaris сказал:

ATSAMC21 нельзя использовать PLL, у него точность оказалась даже ниже, чем у внутреннего генератора

Какая частота была подана на кан ?

[jcxz 183]

В 16.12.2019 в 21:24, Polaris сказал:

в ATSAMC21 нельзя использовать PLL, у него точность оказалась даже ниже, чем у внутреннего генератора

А что такое "точность PLL"? Разве PLL имеет какую-то погрешность?   Интересно узнать её природу - чем она вызвана, если там цифровые делители?

Другое дело - джиттер. Это да - есть. Но это не точность.

[Arlleex 131]

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

Интересно узнать её природу - чем она вызвана, если там цифровые делители?

ИМХО, вполне возможно. ГУН же аналоговый. От адекватности и прямолинейности в зависимости f(U) будет зависеть и выходная частота.

А хрен пойми что, поделенное на цифровом делителе, есть ни что иное, как хрен пойми что

Тот же LPC1768 (как помню): CAN и USB нельзя тактировать от PLL, если источником этого PLL будет не кварц, а внутренний RC.

[jcxz 183]

18 минут назад, Arlleex сказал:

ИМХО, вполне возможно. ГУН же аналоговый. От адекватности и прямолинейности в зависимости f(U) будет зависеть и выходная частота.

А ГУН - при чём? PLL - это умножитель частоты, подаваемой на его вход. Он сам её не генерит, а значит на её погрешность не влияет.

18 минут назад, Arlleex сказал:

А хрен пойми что, поделенное на цифровом делителе, есть ни что иное, как хрен пойми что

Вот именно. Т.е. понимаете, что сам делитель тут не при чём.

[Arlleex 131]

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

А ГУН - при чём? PLL - это умножитель частоты, подаваемой на его вход. Он сам её не генерит, а значит на её погрешность не влияет.

ГУН, он же VCO - сердце PLL (он же ФАПЧ).

Умножения частоты там не происходит. Там происходит деление сигнала с заведомо ВЧ-генератора.

Поэтому точность выходной частоты PLL напрямую зависит от разброса входной частоты и точности этого самого ГУН-а.

 

P.S. Хотя, скорее всего, правильнее будет сказать, что точность выходного сигнала по частоте зависит все-таки только от точности опорной частоты.

[jcxz 183]

13 минут назад, Arlleex сказал:

Умножения частоты там не происходит. Там происходит деление сигнала с заведомо ВЧ-генератора.

Поэтому точность выходной частоты PLL напрямую зависит от разброса входной частоты и точности этого самого ГУН-а.

Я знаю как работает PLL. И не зависит никак точность выходной частоты PLL от его ГУН. А зависит только джиттер этой частоты.

Так как частота этого ГУН непрерывно сравнивается с входной эталонной частотой. И какая разница насколько этот ГУН точный если он управляется цепью ОС от схемы сравнения?

Зависит только джиттер, который появляется из-за конечности скорости реакции ОС.

13 минут назад, Arlleex сказал:

P.S. Хотя, скорее всего, правильнее будет сказать, что точность выходного сигнала по частоте зависит все-таки только от точности опорной частоты.

Вот именно...

[Arlleex 131]

Кстати, по поводу CAN на атмеловских поделиях.

Столкнулся с аппаратным багом на ATSAMA5D в модуле CAN. Может, этот модуль кочует от чипа к чипу, не знаю, просто как информация.

 

Определяем (сколько их там, 8 вроде?) > 1 мэйлбокса на передачу данных, остальные на прием. Допустим, первый отправляет данные с ID 0x1, а второй с 0x2.

Интенсивно отправляем данные. Если кабельная сеть сделана надежно (то есть нет нигде "плавающих" контактов и т.д.), то все будет ок.

Если взять и в процессе транзакций шурудить кабеля туда сюда, вызывая поток ошибок всех типов в CAN-шине, то среди кадров данных время от времени будут появляться "битые".

То есть в сообщении с ID 0x1 будут лежать данные, которые на самом деле были записаны в другой мэйлбокс с ID 0x2 при отправке передатчиком. Или наоборот. Как получится.

Никакими сбросами мэйлбоксов это не лечится. То есть даже не известен момент, когда все пошло поехало.

Проявляется редко даже при частом передергивании кабелей. Но проявляется.

 

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

На приеме при ловле глюка получаю, например, в сообщении с ID 0x1 данные 0x5678. Это однажды сыграло очень злую шутку в целой серии промышленных приборов.

Лечится определением только одного передающего мэйлбокса и построением программной очереди на отправку пользовательских фреймов.

 

Возможно, косяк где-то в выходных аппаратных буферах и логике, копирующей содержимое заполненных мэйлбоксов в выходной сдвиговый регистр (или шо там?).

Может, поможет кому-нибудь.

[jcxz 183]

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

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

На приеме при ловле глюка получаю, например, в сообщении с ID 0x1 данные 0x5678. Это однажды сыграло очень злую шутку в целой серии промышленных приборов.

Раз ID 0x1 выиграл арбитраж, значит ID 0x2 должен был его проиграть и перейти в рецессивное состояние уже на 1-м бите ID. Почему-то ID 0x2 этого не сделал, а видимо продолжил передачу своих данных, а ID 0x1 - наоборот - прекратил (из-за ошибки?). Как вариант. Это если косяк в передающем тракте, а не в приёмнике. Где именно - неплохо было бы выяснить посадив на шину стороннего наблюдателя (сниффер) и посмотрев, что реально передавалось в этот момент. И тогда было бы яснее где искать баг.