Печать

Пожалуйста, войдите или зарегистрируйтесь.
1 час 1 день 1 неделя 1 месяц Навсегда

[KDM]

Здравствуйте!
Использую процессорный модуль Тион270, отладочную плату Сириус270, адаптер SPI-CAN v2.0 и для отладки компьютер с платой компании Марафон и программой CANwise.

Так как устройство can0 на тионе присутствует в списке, поддержка CAN вроде бы должна быть обеспечена, но взаимодействие между устройствами отсутствует :(

ПРИЕМ
Запускаю сеанс связи:
1. # ifconfig can0 down
2. # echo 0 > /sys/class/can/can0/listen_only
3. # ifconfig can0 up
4. # /usr/can-test

Код: [Выделить]

can-test: Read mode
   ID, hex Length Data, hex
5. Запускаю поток данных с компьютера.

Результат: Тион данные благополочно игнорирует, хотя на линии данные есть (проверяю осциллографом, изменяющийся сигнал на CAN_H и CAN_L).

Код: [Выделить]

can-test: Receive packets: 0, errors: 0
ПЕРЕДАЧА
С передачей все выглядит еще интереснее:

Код: [Выделить]

# /usr/can-test -e 0x00 -l 8 -d 123456789abcdef
can-test: ext. id, hex: 0
can-test: length: 8
can-test: data, hex: 01 23 45 67 89 AB CD EF
...........wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww[ 2939.000000] NETDEV WATCHDOG: can0: transmit timed out.wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww[ 2949.000000] NETDEV WATCHDOG: can0: transmit timed out.wwwwwwwwwwwwwwwwwwwwwwwwwww
can-test: Send packets (-1): 13, errors: 0Никаких изменений на линиях нет.

Если после "мнимой передачи" запустить на прием:

Код: [Выделить]

# /usr/can-test

Код: [Выделить]

can-test: Read mode
   ID, hex Length Data, hex
[ 2969.000000] NETDEV WATCHDOG: can0: transmit timed out
+        0 8 EF CD AB 89 67 45 23 01
[ 2979.000000] NETDEV WATCHDOG: can0: transmit timed out
+        0 8 EF CD AB 89 67 45 23 01
[ 2989.000000] NETDEV WATCHDOG: can0: transmit timed out
+        0 8 EF CD AB 89 67 45 23 01 ...
Ловятся "свои" же посылки.
При этом абсолютно без разницы подключен или нет при этом компьютер-приемник.

ДОПОЛНИТЕЛЬНЫЕ СВЕДЕНИЯ.
1. Отключил компьютер, проверил линии CAN_H и CAN_L от тионовского адаптера: на CAN_H и CAN_L напряжение присутствует, одинаковое, примерно +3В.
2. Контакты:

Адаптер	Сириус
X1 PIN1 (SCK)	J4 PIN32 (SSP_CLK)
X1 PIN2 (+3,3B)	J12 PIN6 (+3,3B)
X1 PIN3 (нет)	-
X1 PIN4 (GND)	J4 PIN6 (GND)
X1 PIN5 (SO)	J12 PIN31 (SSP_RXD)
X1 PIN6 (GND)	J4 PIN6 (GND)
X1 PIN7 (SI)	J12 PIN32 (SSP_TXD)
X1 PIN8 (GND)	J4 PIN6 (GND)
X1 PIN9 (INT)	J6 PIN10 (GPIO105)
X1 PIN10 (CS)	J6 PIN14 (GPIO108)

Контакты для разъема X5 разведены.
3. Изменение уровней при запуске сеанса приема-передачи.
**изменение уровня обозначено через "-" в случае кратковременного изменения, "..." означает продолжительность значения
***когда в потоке приема появляется точка (а не w), импульс в 0 и обратно в 1

	ВКЛ	ЗАГРУЗКА	ifconfig can0 down	echo 0 > /sys/class/can/can0/listen_only	ifconfig can0 up	/usr/can-test	/usr/can-test -e 0x00 -l 8 -d 123456789abcdef
CS (R7)	0	0...0-1...1-0-1...1	1...1-0-1...1 или 1	1	1...1-0-1...1	1	***
SO (R8)	0	0...0	0	0	0	0	0
SI (R9)	0	0...0	0	0	0	0	0
SCK (R10)	0	1...1	1	1	1	1	1
INT (R11)	1	1...1-0...0	0	0	1	1	1

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

[KDM]

Причина неисправностей пока что осталась неизвестной.

Но было выяснено, что следующая последовательность действий:
1. Запуск потока данных с компьютера.
2. # /usr/can-test
3. С параллельного терминала на тион, без выхода из программы can-test:
3.1. # ifconfig can0 down
3.2. # echo 0 > /sys/class/can/can0/listen_only
3.3. # ifconfig can0 up
Приводит к успешному получению и передаче данных.

Видимо, придется в комплект поставки включать бубен :D

[asv]

1. У вас есть в dmesg сообщение "mcp251x spi1.0: found CAN interface, listen only mode"?

2. > Контакты для разъема X5 разведены.
Т.е. на X5 адаптера подано 5В?

3. Изменение уровней:
> SI (R9)   0   0...0   0   0   0   0   0
Это значит, что SPI-вход адаптера никогда не изменяется?

[asv]

Но было выяснено, что следующая последовательность действий:
1. Запуск потока данных с компьютера.
2. # /usr/can-test
3. С параллельного терминала на тион, без выхода из программы can-test:
3.1. # ifconfig can0 down
3.2. # echo 0 > /sys/class/can/can0/listen_only
3.3. # ifconfig can0 up
Приводит к успешному получению и передаче данных.

Такого не должно быть. Такое шаманство всегда работает?

[KDM]

> 2. > Контакты для разъема X5 разведены.
> Т.е. на X5 адаптера подано 5В?
Да.

> 1. У вас есть в dmesg сообщение "mcp251x spi1.0: found CAN interface, listen only mode"?
В dmesg|tail этого не появлялось; полный лог загрузки просматривал бегло, одну строчку мог и не заметить. Завтра проверю.

> 3. Изменение уровней:
>> SI (R9)   0   0...0   0   0   0   0   0
>Это значит, что SPI-вход адаптера никогда не изменяется?
Опять же: до того как заработало, сигналов на SI и SO не было (правды ради отмечу, что уровни проверялись при выходах CAN, "подвешенных в воздухе"; но, с другой стороны, на mcp2515 данные должны были бы приходить все равно; по-меньшей мере, CAN плата компьютера передавала сигналы даже если на линии не было ни одного устройства).

> Такого не должно быть. Такое шаманство всегда работает?
Это работало стабильно (5 раз из 5), ни одного сбоя пока что не было, самого очень удивляет.
Несколько раз сработало даже так:
1. Запуск потока данных с компьютера.
2. # ifconfig can0 down
3. # echo 0 > /sys/class/can/can0/listen_only
4. # ifconfig can0 up
5. # /usr/can-test
Выходит, что получение данных очень критично к тому, чтобы ДО действий с CAN на тионе УЖЕ была запущена передача данных с копьютера.
Что весьма неудобно. Ведь хотелось бы сначала наладить связь и уже только потом отсылать данные.

Завтра буду более предметно проверять, что необходимо для нормального обмена данными.

[KDM]

> 1. У вас есть в dmesg сообщение "mcp251x spi1.0: found CAN interface, listen only mode"?
Да, есть.

Попробовал по-разному позапускать.

СХЕМА А.

1. Запуск потока данных с компьютера.	1. Данные отправляются с ошибками write timeout (есть сигнал на линиях CAN_H и CAN_L).
2. # /usr/can-test	2. Данные отправляются с ошибками write timeout. Данные не приходят.
3. С параллельного терминала на тион, без выхода из программы can-test:	3. -
3.1. # ifconfig can0 down	3.1. -
3.2. # echo 0 > /sys/class/can/can0/listen_only	3.2. -
3.3. # ifconfig can0 up	3.3. Данные отправляются и получаются без ошибок.

СХЕМА Б

1. Запуск потока данных с компьютера.	1. Данные отправляются с ошибками write timeout (есть сигнал на линиях)
2. # ifconfig can0 down	2. -
3. # echo 0 > /sys/class/can/can0/listen_only	3. -
4. # ifconfig can0 up	4. -
5. # /usr/can-test	5. Данные получаются без ошибок (сработало 3 раза из 10). Теперь уже данные стабильно не приходят.

СХЕМА Д

1. Запуск потока данных с компьютера.	1. Данные отправляются с ошибками write timeout (есть сигнал на линиях).
2. # ifconfig can0 down	2. -
3. # echo 0 > /sys/class/can/can0/listen_only	3. -
4. # ifconfig can0 up	4. -
5. # ifconfig can0 down	5. -
6. # ifconfig can0 up	6. Данные отправляются без ошибок.
7. # /usr/can-test	7. Данные отправляются и получаются без ошибок. Работает стабильно.

СХЕМА В

1. # ifconfig can0 down	1. -
2. # echo 0 > /sys/class/can/can0/listen_only	2. -
3. # ifconfig can0 up	3. -
4. Запуск потока данных с компьютера.	4. Данные отправляются с ошибками write timeout (есть сигнал на линиях).
5. # /usr/can-test	5. Данные отправляются с ошибками write timeout. Данные не приходят.
6. CTRL + C (остановка can-test)	6. -
7. # ifconfig can0 down	7. -
8. # ifconfig can0 up	8. Данные отправляются без ошибок (ВНИМАНИЕ: при выключенной программе can-test).
9. # /usr/can-test	9. Данные получаются без ошибок.

СХЕМА Г

1. Запуск потока данных с компьютера.	1. Данные отправляются с ошибками write timeout (есть сигнал на линиях).
2. # ifconfig can0 down	2. -
3. # ifconfig can0 up	3. -
(4. # ifconfig can0 down)	(4. -) | - ничего не меняют
(5. # ifconfig can0 up)	(5. -) |
6. # ifconfig can0 down	6. -
7. # echo 0 > /sys/class/can/can0/listen_only	7. -
8. # ifconfig can0 up	8. Данные отправляются без ошибок (ВНИМАНИЕ: при выключенной программе can-test).
9. # /usr/can-test	9. Данные отправляются и получаются без ошибок.

СХЕМА Е

1. Старт сеанса связи на компьютере.	1. - //Уровни на тионе: CS=1, S0=0, SI=0, SCK=1, INT=1. Команда: cat /sys/class/can/can0/listen_only  Ответ: 1.
2. # ifconfig can0 down	2. -
3. # echo 0 > /sys/class/can/can0/listen_only	3. - //Команда: cat /sys/class/can/can0/listen_only  Ответ: 0.
4. # ifconfig can0 up	4. -
(5. # ifconfig can0 down)	(5. -) | - ничего не меняют
(6. # ifconfig can0 up)	(6. -) |
7. # /usr/can-test -e 0x00 -l 8 -d 123456789abcdef	7. Ошибки передачи данных на тионе (write timeout). Прием данных не осуществляется, сигнал на линиях CAN_H и CAN_L отсутствует, есть только постоянное напряжение. Следующие линии имеют постоянный уровень: CS=1, S0=0, SI=0, SCK=1, INT=1.
8. CTRL + C (остановка can-test)	8. -
9. Запуск потока данных с компьютера.	9. Данные отправляются с ошибками write timeout (есть сигнал на линиях CAN_H и CAN_L).
10. # /usr/can-test	10. Данные отправляются с ошибками write timeout (есть сигнал на линиях CAN_H и CAN_L). Данные не приходят. Вместо них (вероятно, из какого-то буфера читается свои же посылки - 123456789abcdef)
11. С параллельного терминала на тион, без выхода из программы can-test:	11. -
12.1. # ifconfig can0 down	12.1. -
12.2. # echo 0 > /sys/class/can/can0/listen_only	12.2. -
12.3. # ifconfig can0 up	12.3. -

Из "Г" можно сделать вывод, что пока listen_only установлен в "0", данные с компьютера отправляются с ошибками "write timeout", поскольку на шину не приходит подтверждение приема.
"В" показывает, что для получения данных надо при идущем идущем потоке выключить и включить CAN интерфейс, без этого никак. Причем как следует из "Б" и "Д", после перезаписи параметра включения передачи, для стабильной работы необходимо еще раз перезапустить CAN интерфейс.
Непонятно, в чем разница между "Б" и "Д". При этом "Б" перестала работать, в то время как "Д" работает стабильно.
Из "Е" четко видно, что никакого чтения после неудачной попытки записи ждать не стоит.


Кстати, "Е" полностью убил всю хрупкую работоспособность всех схем. Уже часа 3 ничего не работает...

//Скорее всего, проблемы с DD3, AM1D-0505SZ, потому что напряжение на выходе 0,02 В

[asv]

> Из "Г" можно сделать вывод, что пока listen_only установлен в "0", данные с
> компьютера отправляются с ошибками "write timeout", поскольку на шину не
> приходит подтверждение приема.

Да.

> "В" показывает, что для получения данных надо при идущем идущем потоке
> выключить и включить CAN интерфейс, без этого никак.  Причем как следует из
> "Б" и "Д", после перезаписи параметра включения передачи, для стабильной
> работы необходимо еще раз перезапустить CAN интерфейс.  Непонятно, в чем
> разница между "Б" и "Д". При этом "Б" перестала работать, в то время как "Д"
> работает стабильно.  Из "Е" четко видно, что никакого чтения после неудачной
> попытки записи ждать не стоит.

Видимо проблема с программным включением (sleep/wakeup) микросхемы MCP2515.

> Кстати, "Е" полностью убил всю хрупкую работоспособность всех схем. Уже часа
> 3 ничего не работает...

Даже после выключения и включения питания?

> AM1D-0505SZ
DC/DC не замкнуто, не греется?

[KDM]

> Даже после выключения и включения питания?
Это не помогало.

> AM1D-0505SZ DC/DC не замкнуто, не греется?
Не греется. Но при нормальном входном напряжении (+5В) на выходе дает всего лишь 0,02В.

Выпаяли DD3 и поставили вместо него перемычки R1 и R2. Пока что обойдемся без гальванической развязки питания.
Все снова заработало.

[asv]

Как может измениться логика, если драйвер тот же.

[asv]

У вас есть возможность и/или желание пробовать драйвер для это SPI-CAN контроллера в более новых ядрах Linux?

[KDM]

Все же некоторые изменения есть.

СХЕМА Е*

1. Старт сеанса связи на компьютере.	1. - //Уровни на тионе: CS=1, S0=0, SI=0, SCK=1, INT=0. Команда: cat /sys/class/can/can0/listen_only  Ответ: 1.
2. # ifconfig can0 down	2. -
3. # echo 0 > /sys/class/can/can0/listen_only	3. - //Команда: cat /sys/class/can/can0/listen_only  Ответ: 0.
4. # ifconfig can0 up	4. - //Уровни на тионе: CS=1, S0=0, SI=0, SCK=1, INT=1.
(5. # ifconfig can0 down)	(5. -) | - ничего не меняют
(6. # ifconfig can0 up)	(6. -) |
7. # /usr/can-test -e 0x00 -l 8 -d 123456789abcdef	7. Ошибки передачи данных на тионе (write timeout). Прием данных не осуществляется, сигнал на линиях CAN_H и CAN_L отсутствует, есть только постоянное напряжение. Следующие линии имеют постоянный уровень: CS=1, S0=0, SI=0, SCK=1, INT=1, TXCAN=1, RXCAN=1.
8. CTRL + C (остановка can-test)	8. -
9. Запуск потока данных с компьютера.	9. Данные отправляются с ошибками write timeout (есть сигнал на линиях CAN_H и CAN_L).
10. # ifconfig can0 down	10. -
11. # ifconfig can0 up	11. Данные отправляются без ошибок. В этот момент компьютер ловит одну посылку с тиона.
12. # /usr/can-test	12. Данные отправляются и получаются без ошибок.
13. CTRL + C (остановка can-test)	13. -
14. # /usr/can-test -e 0x00 -l 8 -d 123456789abcdef	14. Данные с тиона отправляются и получаются без ошибок.

> Видимо проблема с программным включением (sleep/wakeup) микросхемы MCP2515.
Очень на это похоже.
Если принять за предположение проблему с программным включением mcp2515, получается, что из режима сна она выходит только а) при наличии данных на шине б) в момент включения CAN интерфейса. Хотя в даташите написано что вроде бы достаточно просто активности на шине. Да и INT все же изменяет свое значение с 0 на 1 при включении CAN интерфейса, должно бы выводить из сна.

> У вас есть возможность и/или желание пробовать драйвер для это SPI-CAN контроллера в более новых ядрах Linux?
К сожалению, в настоящий момент у меня нет такой возможности. Особенно учитывая проблемы с конфигами для новых ядер.
Других вариантов решения случайно не существует?

[asv]

> Хотя в даташите написано

Есть ещё список ошибок, errata.

> Других вариантов решения случайно не существует?

Даже при других вариантах, это даст понимание насколько устраивает работа драйвера включённого в ядро. Так как если что-то и править, то имеет смысл править только драйвер включённый в ядро.

С конфигурацией я могу помочь, но через две недели.