lprot

Все признаки указывают на то, что uart break является важной составляющей коммуникации между прошивкой infineon и прошивкой модуля bluetooth.
У меня процесс выглядит так:
1. При подаче питания на адаптер, infineon на скорости uart 9600 бит/c, выдает строку 0c 01 0b 09 90 d2 8f af 57 57 55 6f 60 (это никакого отношения к обмену с bluetooth не имеет, но интересный нюанс)
2. Запускается прошивка infineon, устанавливает скорость uart 921600 бит/с, начинает мигать светодиодом VAS5054 и ждет команды по протоколу PDU, считая что bluetooth модуль находится в прозрачном режиме
3. Как только приходят команды 00 ff 01 00 04 00 ff 30 0b 00 (посылается при нажатии кнопки reset to default в EDICConfig) или 00 ff 01 00 04 00 ff 30 0f 00 (посылается при нажатии кнопки настройки и при записи настроек в EDICConfig), прошивка infineon шлет uart break прошивке модуля bluetooth (фактически коротит ногу RX модуля bluetooth на землю какое-то количество миллисекунд) . И ждет обратной реакции (что именно пока не ясно, но скорей всего uart break в ответ). После этого, прошивка Infineon считает, что bluetooth модуль вышел из прозрачного режима в режим команд и начинает с ним общаться уже на протоколе LMX9830.

На прошивке bc417 есть сложности с определением uart break и с посылкой ответа так, как в прошивке просто напросто нет инструментов для посылки/приема сигнала uart break.
Идея у меня следующая - можно использовать один из pio выводов (просто забросить на него перемычку на ногу tx и генерировать сигнал, когда нужно).
Другой, более простой путь, это пропатчить прошивку infineon, чтоб он не требовал подтверждения uart break...

Надеюсь что логи покажут что infineon нужен не uart break, а что-то другое, но результаты моих многочисленных экспериментов пока говорят другое.