MCP2515, дубль 2
Jul. 1st, 2008 05:28 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
kincajou00: 00 00 00 00 00 00 00 00 00 00 00 00 3C 05 40 45 ................ 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40 45 ................ 20: 00 00 00 00 00 00 00 00 02 62 02 BF 00 00 40 45 ................ 30: 00 5A 20 54 02 4F 50 41 54 54 45 52 4E 31 40 45 ......PATTERN1.. 40: 00 A5 20 03 04 07 2D 2D 50 69 50 41 54 54 40 45 ......--PiPATT.. 50: 00 A5 40 05 06 0B 53 65 6C 66 54 65 73 74 40 45 ......SelfTest.. 60: 06 69 A8 0A 4E 3B 51 E2 6E CE 3D FA E4 4C 40 45 ................ 70: 00 92 10 7E 7D 59 B8 E3 63 3B D6 95 73 95 40 45 ................
Я офигеваю ваще. Эта гадская чипуха умудряется портить записанные в неё данные сразу же после записи! Дамп выше - это её память, считанная прямо после процедуры инициализации.
Выделил справа те символы, которые должны быть такими:
PATTERN1 --Ping-- SelfTest
Как видим, вторая строчка поломалась (похоже, что на неё как-то наслоился фрагмент первой).
Кроме того, первые три строки, почти полностью занятые нулями, должны быть заполнены совсем не ими, а специфическими константами, которые я туда токашо записал. Где они?
1) Узел А кладёт в свой TX буфер сформированный кадр №1 и начинает передачу
2) *что-то происходит* и узел А решает, что надо повторить передачу кадра - и он повторяет, повторяет, повторяет...
3) Если посмотреть в RX буфер узла Б, то в нём пока ничего нет (кроме мусора, оставшегося после power-on)
3) Узел Б, ничего не "подозревая" о происходящем на шине (а там продолжает колбаситься узел А), готовит свой кадр №2 и начинает передачу. В этот момент он внезапно принимает кадр №1 - удивлению его нет границ. Кадр помещается в буфер, генерится прерывание и - о, чудо! - процессор узла Б наконец-то получает долгожданные данные от узла А. А узел А, в свою очередь, наконец-то успокаивается. 4) ...и получает кадр №2 от узла Б.
Ergo до тех пор, пока удалённый узел не вышлет какой-то пакет данных (любой), передающая сторона будет повторять передачу, ровным слоем насрав на то, что подтверждение ДОЛЖНО генерироваться железом сугубо автоматически - этот процесс программисту абсолютно неподконтролен.
Казалось бы - ну и хер бы с ним, раз так ндао высылать ответный кадр, будем высылать... Но! А как мы узнаем, что это надо сделать? В буфере ничего нет, прерывания тоже нет - момент этот угадывать, что ли? Потому что если попытаться просто так выслать кадр, в какой-нибудь отвлечённый момент, то ситуация повторится для узла Б точно так же.
Короче говоря, трансиверы MCP2515 ведут себя НЕНОРМАЛЬНО и возможно триварианта:
1) либо в даташите что-то умалчивается, а я не знаю. И программы, соотв., получаются нефункциональными
2) либо это бракованная партия, которая просто глючит
3) либо я шизофреник и мне всё это кажется.
Склоняюсь к третьему варианту...
Upd зарубежный товарищ столкнулся с подозрительно похожей проблемой. Но у меня хотя бы дифференциальный сигнал на магистрали есть: when the CAN Tx error counter TEC gets stuck at 128 decimal and you have never ending CAN Tx automatic retries, it means the only error is no ACK response
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2008-07-01 01:43 pm (UTC)Может микросхема битая или задержки при записи слишком маленькие?
no subject
Date: 2008-07-01 01:55 pm (UTC)Причём, похоже, я нашёл то ли глюк ЦПУ, то ли компилятор козлит - когда размер кода превышает какой-то порог (но НЕ объём флэшки, там ещё есть место), то процессор вообще не стартует или начинает исполнение программы со случайного адреса
О_о
no subject
Date: 2008-07-01 01:58 pm (UTC)no subject
Date: 2008-07-01 02:17 pm (UTC)no subject
Date: 2008-07-01 02:20 pm (UTC)no subject
Date: 2008-07-01 02:35 pm (UTC)Но предыдущий глюк с генерацией прерываний остался
no subject
Date: 2008-07-01 02:43 pm (UTC)no subject
Date: 2008-07-01 03:17 pm (UTC)Проблема основная - не генерятся прерывания о приёме данных. И, как показывает вскрытие, они вообще не принимаются, пока что-нибудь не попытаешься выслать наружу
no subject
Date: 2008-07-01 03:32 pm (UTC)no subject
Date: 2008-07-01 03:55 pm (UTC)Это, а "физика" _точно_ правильная? Линия; уровни сигналов, их форма; нет ли расхождения по частотам (не уплывает ли синхронизация между контроллерами); нет ли расхождения по скоростям приема-передачи (иногда это не проверяется на аппаратном уровне; тогда сигнал "старт" окажется незамеченным) и все такое?
no subject
Date: 2008-07-01 04:03 pm (UTC)Я написал программу второй раз, с нуля. Та же хуйня осталась - либо я где-то допускаю систематическую ошибку, либо мне пора лечиться. Я этот пост обновил - глянь, что оно вытворяет.
no subject
Date: 2008-07-02 10:02 am (UTC)Вдогонку: а в других режимах эта самая связь работает?
no subject
Date: 2008-07-02 11:21 am (UTC)Разделение на ведущих/ведомых может быть на более высоком уровне, но в данной ситуации их точно нет.
В режиме Loopback работает, естественно. А в других режимах не пробовал (ещё есть sleep, в котором вообще всё вырублено, и listen-only, когда дивайс слушает шину, но ничего не передаёт)