Цитата:
|
Немного дополню. Кроме прослушки виртуального ком порта блютуза ( между модулем блютуз и ПДУ) надо физически подцепиться на прослушку rx tx линии между инфинеоном и модулем блютуз и записывать какие команды посылает ПДУ в модуль блютуз, а тот в свою очередь в инфинеон. Их не так и много. И на основании этих данных править прошивку блютуза.
Тут есть парни с оригиналами. Помогите доработать).
|
По расшифровке протокола соединения между EDICConfig и Infineon в предыдущем сообщении у меня вопросов нет:
f0 f1 f2 f3 - посылается EDICConfig и означает окончание передачи
f5 f4 f3 f2 f1 f0 посылается из операционки Infineon и означает, что посылка принята
00 ff 04 00 02 00 aa 01 - команда запроса, где 00ff это заголовок, 04 00 перевернутые байты 0004 (код команды), 02 00 перевернутые байты 0002 длина данных в байтах, aa 01 = 01aa данные. Завершается посылка опять же f0 f1 f2 f3.
Далее подтверждение f5 f4 f3 f2 f1 f0 от Infineon, что команду он принял и понял.
00 ff 01 00 02 00 ff 40 - команда 1, с 40ff запрос имени адаптера и PIN кода bluetooth
Ответ от Infineon
00 ff 01 00 0e 00 00 00 56 41 53 35 30 35 34 00 .я......VAS5054. bd 71 e5 04 Ѕqе.
04e571bd это в десятичном виде ничто иное как 082145725
С этим вроде как все понятно.
А вот лог когда мы нажимаем кнопку настройка в EDICConfig:
[11/09/2019 21:11:28] - Open port COM6 (C:\Program Files (x86)\Softing\EdicDriver\EDICConfig.exe)
[11/09/2019 21:11:31] Written data (COM6)
f0 f1 f2 f3 рсту
[11/09/2019 21:11:31] Read data (COM6)
f5 f4 f3 f2 f1 f0 хфутср
[11/09/2019 21:11:31] Written data (COM6)
00 ff 04 00 02 00 aa 01 .я....Є.
[11/09/2019 21:11:31] Written data (COM6)
f0 f1 f2 f3 рсту
[11/09/2019 21:11:31] Read data (COM6)
f5 f4 f3 f2 f1 f0 хфутср
[11/09/2019 21:11:31] Written data (COM6)
00 ff 01 00 04 00 ff 30 0e 00 .я....я0..
[11/09/2019 21:11:31] Read data (COM6)
00 ff 01 00 03 00 00 00 01 .я.......
[11/09/2019 21:11:31] Written data (COM6)
01 fe 01 00 04 00 ff 30 0f 00 .ю....я0..
[11/09/2019 21:11:32] Read data (COM6)
02 52 4e 01 00 a1 .RN..Ў
[11/09/2019 21:11:46] - Close port COM6
С началом диалога EDICConfig все понятно, интересное начинается с
00 ff 01 00 04 00 ff 30 0e 00 где 00ff - заголовок, 0001 команда, 0004 длина данных, 30ff 000e данные.
Ответ 00 ff 01 00 03 00 00 00 01 - 00ff заголовок, 0001 команда, 0003 длина, 010000 данные
Затем следует запрос от EDICConfig 01 fe 01 00 04 00 ff 30 0f 00
На что приходит ответ 02 52 4e 01 00 a1
А вот тут самое интересное. Дело в том, что этот ответ не должен попадать к EDICConfig, а должен быть отработан прошивкой bluetooth чипа. Если посмотреть руководство по программированию LMX9830 (вложил аттачем), расшифровка такая:
02 - start delimiter (разделитель данных) 52 - packet type indicator (индикатор типа пакета, 52=REQ запрос), 4e - opcode (код команды), 01 - длина payload, 00 - payload, a1 - checksum (считается как последний байт суммы 0x52+0x4e+0x01 - packet type+opcode+длина payload).
4e - это команда SET_EVENT_FILTER.
Ответ на 02 52 4e 01 00 a1
Должен быть передан прошивкой bluetooth модуля в Infineon
02 43 4e 01 00 92 где индикатор типа пакета 43 = СFM подтверждение.
Как же отличает эту команду bluetooth прошивка чипа LMX9830? Согласно мануала из атача, есть такая последовательность данных как UART break. Получается Infineon получив команду 01 fe 01 00 04 00 ff 30 0f 00 делает UART break, переводя режим работы прошивки модуля bluetooth из прозрачного режима в режим команд и соответственно команда SET_EVENT_FILTER должна прийти не к EDICConfig, а в прошивку bluetooth модуля. Ну и по завершению обмена, Infineon переводит прошивку в прозрачный режим и ответ уже передается EDICConfig.
Так как в текущем состоянии прошивка не умеет реагировать на UART Break и ответ Infineon адресованный прошивке bluetooth чипа пробрасывается EDICConfig, он не получив ожидаемый ответ выдает ошибку "Device is not accessible".
Если кто-то возьмется за реализацию данной затеи, готов передать исходники и рассказать что куда и как...