[РЕШЕНО] RENESAS FDT, R8C and USB->RS232 converters., Вопрос к технической поддержке RENESAS Опции

[Shema]

У меня мало знаний о контроллерах Renesas. Когда я запутался в настройке программного и аппаратного обеспечения... Я решил обратиться за поддержкой в ​​Renesas. До этого я перепробовал все возможные упражнения, которые только мог придумать, чтобы заставить это работать, но безрезультатно. Вероятно, я задаю им глупые вопросы, потому что они меня вообще не понимают... Я ищу профессиональное мнение о том, как продолжать с ними общаться или сдаться. Кому можна интересно, вот оно. RENESAS

Сообщение отредактировал Shema - 26.4.2025, 8:35

[Shema]

Я как-то читал R5F2136CS с FDT и E8. Я сделал это видео для кого-то, но не помню... если хотите, посмотрите. Но это уже другой вопрос. https://youtu.be/Ve6tU5In020

говорил нужен именно UART Mode 2. Режим UART Mode 3 - не поддерживается этой связкой

Я никогда не обращал внимания на USB->RS232 и FDT, потому что у меня были все остальные необходимые инструменты. Я проверю... когда у меня будет время, я перестрою свой мост и дам FDT MODE2... может быть, кролик оттуда вылезет

[Skvo]

Я как-то читал R5F2136CS с FDT и E8. Я сделал это видео для кого-то, но не помню... если хотите, посмотрите. Но это уже другой вопрос. https://youtu.be/Ve6tU5In020

Ты читал другой проц - R5F2136CA
Он официально поддерживается в FDT программатором E8A. Через твой трюк, можно сделать ему неофициально поддержку E8, тут я согласен...


Но, я выше писал про процессор R5F2136CS.
Он не поддерживается ни E8, ни E8A...
Трюк с редактированием файла конфигурации - тут уже не поможет. Программатор хоть и появится в списке, но работать всё равно не станет... Проверено неоднократно...
Для R5F2136CS нужен обязательно программатор Renesas E1 или E20. Или UART адаптер... Никакие другие программаторы от Renesas не заставишь работать с этим процом через FDT...

[Shema]

��️ Работа FDT + FTDI + Renesas R8C в Boot Mode 3 (не поддерживается официально FDT)



Описание проблемы:

✔️ Официально FDT поддерживает только Boot Mode 2. !!!
→ В этом режиме используется full-duplex — RX и TX разделены.

❌ В Boot Mode 3 линии RX и TX объединены в одну линию MODE (half-duplex).
→ FDT НЕ поддерживает работу в Boot Mode 3. ???

✅ Решение:

Контроллер загружается в Boot Mode 3, после чего FDT может работать через программный Bridge, который преобразует half-duplex в full-duplex.

Аппаратная схема подключения:

RTS → RESET (напрямую)
DTR → через диод → MODE (формирование TxBreak)
TX → через диод (анод к TX, катод к RX и MODE)
RX → напрямую к MODE

Линия MODE — это фактически продолжение RX. TX подключён к MODE через диод. DTR формирует TxBreak через отдельный диод.

Логика работы:

1. RTS=LOW → RESET активен
2. DTR=LOW → TxBreak активен, MODE=0 (через диод)
3. Через ~50 мс → RTS=HIGH → RESET отпущен
4. DTR держится LOW ещё 200 мс для надёжного входа в загрузчик
5. После этого DTR=HIGH → MODE освобождается для передачи данных
6. Начинается работа по MODE как через объединённую линию RX/TX

Как работает связь:

- TX передаёт данные через диод на MODE
- RX принимает напрямую с MODE
- Линия MODE — общая для передачи и приёма (half-duplex)
- FDT ожидает стандартный full-duplex (разделённые RX и TX), но Bridge выполняет преобразование half-duplex → full-duplex

Настройка портов - 9600:

1. Создать виртуальную пару через com0com → COM10 ↔ COM11
2. COM10 используется Bridge для связи с реальным FTDI-портом (например, COM4)
3. COM11 выбирается в FDT как основной порт
4. В настройках FTDI (Device Manager → USB Serial Port → Properties → Advanced) установить:
Latency Timer → 3 мс (обязательно!)

Почему критичен Latency Timer:

- Скорость 9600 бод → передача одного байта ≈ 1.04 мс
- Если Latency > 16 мс → драйвер USB накапливает до 16 байт → передача пачками → ошибка синхронизации и сбой FDT
- При Latency = 3 мс работает стабильно и корректно, без накопления данных

Порядок работы:

1. Подключить FTDI к контроллеру (COM4)
2. Запустить Bridge → COM10 ↔ COM4
3. Нажать Boot Controller → RTS=LOW, DTR=LOW (активен RESET + TxBreak)
4. Отпустить RESET (RTS=HIGH), затем через ~200 мс DTR=HIGH (TxBreak отпущен)
5. Запустить FDT, выбрать COM11 - Recomended Speed = 9600 !!!
6. Работаем — чтение, запись, стирание работают корректно

Ограничения:

- FDT НЕ может самостоятельно загрузить контроллер в Boot Mode 3 — обязательно выполнять бут через "Буут на Контролера" или вручную по линии RTS/DTR.
- FDT считает, что работает в Mode2, но контроллер реально находится в Mode3 — связь стабильна.

Краткие настройки:

com0com: COM10 ↔ COM11
FTDI COM порт: COM4
Latency Timer FTDI: 3 мс
Bridge: COM10 ↔ COM4
FDT подключается к: COM11 - 9600

Почему метод работает:

- SCI-протокол одинаков для Mode2 и Mode3 .
- Отличие только в способе загрузки (MODE pin)
- После загрузки загрузчик работает абсолютно одинаково в любом режиме
- Bridge преобразует half-duplex в full-duplex для FDT

✔️ Итог:

Позволяет использовать FDT с контроллерами в Boot Mode 3, несмотря на отсутствие официальной поддержки.
Не требует сложного оборудования — достаточно одного FTDI и нескольких диодов.
Полностью устраняет ограничение FDT на работу только в Mode2. !!!

Работает 100%! Проверено.



⚠️ Почему сложно синхронизировать работу USB-COM конвертера с контроллерами Renesas

Работа с микроконтроллерами Renesas через USB-RS232 конвертер (FTDI и аналоги) — это нетривиальная задача, требующая глубокой настройки и понимания ограничений.

Почему это сложно:

✔️ Аппаратный COM-порт (реальный UART) работает напрямую с микросхемой — каждое состояние линии соответствует каждому биту в реальном времени.

❌ USB — это пакетная передача данных. Нет прямого соответствия «бит → линия». Передача идёт блоками через USB стек операционной системы, драйвер, USB контроллер и хост.

✔️ Каждое устройство USB работает в рамках опроса (polling) и передачи пакетами с интервалами, ограниченными драйверами и аппаратной шиной.

❌ В реальном COM порте байт передаётся с задержкой строго 1.04 мс при 9600 бод. В USB-COM адаптере задержка может составлять десятки миллисекунд, если не правильно настроен Latency Timer.

Как выглядит реальная схема передачи:

1. FDT передаёт данные на виртуальный порт COM11 (com0com).
2. Через Bridge данные идут на COM10, который связан с реальным USB→COM портом (например, COM4 на FTDI).
3. USB-драйвер буферизует данные. Передача идёт не по биту, а блоками. В случае стандартных настроек — каждые 16 мс или при накоплении 16 байт.
4. После этого данные уходят на TX линии FTDI и далее на MODE/RX контроллера.
5. Контроллер ожидает строгий SCI-протокол с точным соблюдением таймингов .

Любое отклонение по таймингу приводит к разрыву связи, потере пакета или ошибке записи.

Почему именно с Renesas это особенно критично:

✔️ Загрузчик Renesas (Bootloader) требует строжайшего соблюдения таймингов между байтами.

✔️ Renesas официально в документации и техподдержке заявляют:
"Работа через USB-to-Serial конвертеры невозможна из-за несоблюдения критичных таймингов загрузчика."

✔️ В официальных документах Renesas указано:
"USB-to-Serial converters cannot guarantee the necessary timing for reliable communication with the R8C bootloader."

Как мы обошли это ограничение:

✔️ Используем программный Bridge, который:

- Фильтрует эхо (из-за объединённых RX и TX в линии MODE)
- Минимизирует задержки путём установки Latency Timer = 3 мс
- Быстро пересылает данные, максимально приближённо к реальному COM
- Преобразует Half-Duplex (Mode3) в Full-Duplex, необходимый для FDT

Где возникают риски:

❌ Перегрузка USB-шины может привести к задержкам передачи.

❌ Если оставить Latency Timer = 16 мс (по умолчанию) — вероятность успешного подключения падает практически до нуля.

❌ Неверная последовательность включения бриджа, выбора портов или ошибок в настройках — приводят к сбоям передачи.

Почему всё-таки работает (хотя Renesas пишет, что это невозможно):

✔️ SCI-протокол прост и стабилен.

✔️ Загрузчик после входа в Boot Mode принимает команды последовательно. При правильной работе TX и RX по одной линии (MODE) и фильтрации эхо, он абсолютно корректно обрабатывает данные.

✔️ Использование правильного алгоритма управления RTS и DTR (Boot + Reset + TxBreak) даёт стабильный вход в загрузчик.

✔️ Bridge эффективно разделяет передачу и приём данных в Full-Duplex, подстраиваясь под работу FDT.

Заключение:

✔️ Однако с грамотной реализацией Bridge, корректными схемами подключения, управлением RTS/DTR и настройкой Latency Timer — работа становится абсолютно стабильной и надёжной.

✔️ Вся эта работа — реализация идеи и эксперимента.
Софтуерный бридж и весь стек коммуникации написаны на языке Python с использованием библиотеки Qt5 для графического интерфейса.

Этот проект — вторая крупная самостоятельная разработка на Python и Qt5. Платформа ещё активно изучается, и проект развивается параллельно с освоением инструментов.

На текущий момент работа проверена и протестирована только на одном экземпляре контроллера Renesas R8C.
Планируются дальнейшие тесты с другими устройствами и в различных условиях, когда появится больше времени на доработку и испытания.

✔️ Проект полностью функционален в текущем виде, но пока ещё развивается и оптимизируется.

com0com
EXE
VIDEO

Сообщение отредактировал Shema - 29.6.2025, 20:43