Давным-давно, когда деревья были большими и вариации комплектаций одной модели автомобиля можно было перечислить пальцами одной руки, был куплен диагностический адаптер, о котором сегодня пойдет речь. Творение неизвестного китайца получило название Mini-VCI J2534. Откуда он взялся доподлинно неизвестно, но позиционируется как интерфейс для работы с различными Тойотами, а так же как J2534 совместимый адаптер (спойлер - нет). В момент покупки его было достаточно для диагностики и ковыряния в мозгах автомобилей тех лет, но прогресс не стоит на месте и в нынешних реалиях он если так можно выразиться - "не вывозит". О том, можно ли с этим что-то сделать и пойдет речь ниже.

Итак, знакомьтесь - наш пациент снаружи и внутри:

Внутри него живет 16/32 bit ARM7TDMI-S™ CPU, пара CAN-контроллеров, 2 UART'а и еще кучка полезной и не очень периферии.

Суть проблемы

Если закрыть глаза на мелочи в виде почти полного несоответствия стандарту J2534, есть у него проблемы гораздо хуже, а именно невозможность отправлять данные по протоколу ISO-TP длиннее ~48 байт. С последним мириться было нельзя и в голове засела мысль, а что если получится сделать этот мир чуточку лучше.

Если кратко, как происходит передача данных длинной больше 8 байт по CAN-шине (длина сообщения CAN ограничена восемью байтами). Существует такой стандарт ISO15765, он же ISO-TP (Transport Protocol), который покрывает 2 модели OSI (сетевой и транспортный). Передача данных длиной более 7 байт выглядит так:

1. Источник отправляет First Frame (FF) с данными об общей длине передаваемых данных и первыми 6 байтами payload'а.

2. Приемник отвечает ему Flow Control фреймом, в котором говорит о минимальном допустимом времени между посылками CF (о них ниже) и количестве CF, после которого источник снова должен дождаться Flow Control фрейм.

3. Источник после приема Flow Control'а продолжает отправку данных фреймами Consecutive Frame (CF) с заданным интервалом о ожиданием следующего Flow Control (если об этом было сказано в пункте 2)

   https://en.wikipedia.org/wiki/ISO_15765-2

Что происходит на самом деле и почему ничего не работает нам поможет выяснить обычный анализатор CAN шины (Can Hacker/PEAK CAN и иже с ними). Итак, картина маслом - все смешалось, кони, люди. Приемник сказал жди от меня каждые 8 Consecutive Frame'ов Flow Control и шли мне каждый Consecutive Frame не менее чем через 10 мс, а шнурок мало того, что проигнорировал ожидание FC, так еще и на минимальную задержку между CF не обратил внимания.

Flow Control от приемника - 30 08 0A FFFFFFFFFF, где 08 - количество CF, после которого источник снова должен дождаться Flow Control фрейм, 0A - минимальное допустимое время между посылками CF.

Что мы имеем по факту - задержка около 1мс между CF, вместо желаемой 10мс и отсутствие ожидания Flow Control, что полностью ломает весь процесс передачи.

Ну и ладно, подумаешь, организуем свой ISO-TP с задержками и таймингами, благо шнур позволяет работать с сырыми данными CAN и посмотрим что получилось (гадость какая)

В шнурке используется преобразователь USB-UART FT232, который имеет некоторые проблемы при работе с USB 3.0. И проблемы эти - конские задержки, которые не настраиваются из драйвера, хотя на USB 2.0 все работает, но где вы сейчас найдете честный контроллер USB 2.0 в матери/ноутбуке. В общем, ручное форматирование тоже отпадает, задержки между CF не поддаются критике, работать это тоже не будет.

Остается крайняя мера - залезть внутрь и попробовать исправить кривой софт костылями, насколько это возможно. Не знаю как, но прямо по USB из контроллера можно вычитать и записать флеш память даже без разборки шнурка с помощью программы Flash Magic. После чтения загружаем прошивку в IDA, процессор ARM Little Endian архитектура ARMv4T. Немного помощи руками, создание недостающих регионов и прошивка готова к исследованию.

Функция с реализацией отправки данных по ISO-TP была найдена от обратного (CAN периферия - отправка - обертка - сама функция). Что же по исходникам - вот кусок кода с отправкой данных. То, о чем говорилось выше не предусмотрено вообще никак.

iso_tp_fc_received_ptr = &ctx->iso_tp_fc_received;
while (sended_len < send_len)
{
    if (ff_flag)
    {
        if (cf_counter >= 0xF)
            cf_counter = 0;
        else
            ++cf_counter;
        v21 = 8;
        tx_data.data[0] = cf_counter + 0x20; // Сборка Consecutive frames
        v23 = v21 - 1;
        if (send_len - sended_len < v21 - 1)
            v23 = send_len - sended_len;
        memcpy(&tx_data.data[1], &send_data_[sended_len], v23);
        can_tx_1(ctx, &tx_data);
        sended_len += v23;
    }
    else
    {
        tx_data.data[0] = 0x10;         // Сборка First frame
        tx_data.data[1] = send_len; // Больше 255 байт не предусмотрено, хотя по стандарту должно быть 4 с копейками кб, хотя о чем это я
        memcpy(&tx_data.data[2], send_data_, 6));
        cf_counter = 0;
        set0(iso_tp_fc_received_ptr);
        can_tx_1(ctx, &tx_data);
        if (!wait_fc(ctx, 700)) // Ждем flow control
            return 0;
        ff_flag = 1;
        sended_len += 6;
    }
}

Как видно, Flow Control шнурок ждет всего один раз, а дальше даже не пытается соответствовать ISO-TP. Как только он получит FC, сразу же без задержек начинает слать остатки данных в Consecutive Frame'ах. Ладно, но может он хотя бы обращает внимание на данные из Flow Control? Ха-ха. Нет. Вот функция обработки приема данных по ISO-TP, нас интересует только прием Flow Control.

header = rx_byte_0 & 0xF0;
if (can_rx_ctx->rx_can_data[0] & 0xF0)
{
    switch (header)
    {    
        //Тут были обработчики других заголовков, но они нам не нужны
    case 0x30: //Flow control
        set_1(&iso_tp_ctx->iso_tp_fc_received);
        result = 0;
        break;    
    }
}

Как видим, просто выставляется флажок, что был принят какой-то flow control, а что там в нем нам не важно (мысли китайца).

Что же делать?

Дешево и сердито - засунуть простую задержку между отправкой Consecutive Frame'ов, чтобы приемник успевал отправить свой Flow Control там, где нужно и получил следующий CF уже после. Все что нам нужно, это найти место, в цикле с отправкой, куда можно засунуть переход в функцию с задержкой, благо мест таких полно, а замененные инструкции можно выполнить в новой функции, так что мы ничего не потеряем. Берем IAR, в нем есть поддержка именно такого процессора, чистый проект на ассемблере и пишем элементарный цикл

_my_func
        STMFD   SP!, {R10-R12,LR}
        LDR R10, =39062          ; ~7800 на 1 мс
        B compare
sub:
        SUB     R10, R10, #1
compare:        
        CMP     R10, #0
        BGT sub
        
        MOV     R0, R4          ; та самая замененная инструкция на переход
        LDMFD   SP!, {R10-R12,PC}

Конечный результат выглядит так - слева то, что было, справа то, что стало. Инструкция MOV R0, R4 перенесена.

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

Конечно, можно было сделать все по фен шую, и правильную обработку Flow Control фрейма, и честные задержки по желанию приемника, и ожидание остальных Flow Control'ов. Но результат в любом случае достигнут и терять время больше чем один вечер на такое желания нет.

Еще интересный момент - контроллер судя по всему китайский перемарк, т.к. определился программой по внутреннему ID как LPC2114, в котором, на минуточку, вообще нет CAN контроллера, если верить даташиту. Видишь CAN? И я не вижу, а он есть. Вот так вот.

Кому интересны прошивка и база IDA, то вот. Пароль habr.com