что так? вроде, в sdk встречается uboot.boot_debug, и даже скрипт запуска gdb run_jtag.sh, но куда это вставлять?

Проблема в том, что чип после приёма ключа сначала пытается узнать частоту кварца, чтобы потом правильно настроить PLL и перейти к работе по USB.
Для этого он подтягивает D+ к питанию, потом уже ожидает импульсы на этой самой ноге, и по истечении некоторого времени (около секунды), подтяжка отключается и всё идёт заново.

Так как простой подтяжкой D+ нельзя просто так выйти на High-Speed (USB 2.0) шину, устройство определяется как Full-Speed устройство, поэтому оно подключается вместе к остальным Full/Low-speed (USB 1.1) устройствам на шине (типо клавы/мыши, CH340 и т.п.), и поэтому разговор далее идёт именно про USB 1.1.

У USB 2.0 хабов существует два вида организации TT: STT (Single Transaction Translator) и MTT (Multiple Transaction Translator).

У STT хабов на все порты есть только один TT, поэтому все USB 1.1 устройства делят одну шину, и принцип получается как с USB 1.1 хабами.
Но у MTT хабов на каждом порту уже стоит по своему TT, поэтому каждое устройство имеет свою отдельную шину, которая независима от других устройств.

USB хабы сами по себе устроены так, что когда хост хочет что-то отправить на определённое устройство, хаб отсылает это на все устройства, которые к нему подключены, а ответ уже отсылается обратным путём напрямую к хосту.

Если например использовать USB 1.1 хаб, или STT USB 2.0 хаб, то можно будет наблюдать такой эффект:
Например если в хаб воткнуть CH340 и чип JL, то те пакеты которые идут к CH340, например данные для отправки по UART или запросы на наличие принятых данных, будут также просачиваться к шине где сидит JL чип, или если например JL будет в режиме аудиокарты, и туда передавать звук, то на шине у CH340 можно будет увидеть пакеты с аудио для JL.

Именно это и мешает определению частоты кварца чипом, ибо весь этот шум может либо не привести ни к чему, либо приведёт к неверному определению частоты и, как следствие, к неверным частотам для USB (а то и для всего чипа) и дальнейшой невозможности общения с компом, и всем этим проблемам с определениям устройств, так как приём этих самых SOF пакетов устроен очень примитивно, при помощи захвата таймером ноги D+, понятное дело что таким образом узнать PID у пакета будет невозможно, и как следствие, отличать SOF-ы от других пакетов.

Отредактировано kagaimiq (2023-12-29 03:00:10)

Подпись автора

水Mizu-DEC JLtech since 22.06.2019

Ну, они посчитали, что лучше определять частоту на лету, вместо того, чтобы хардкодить частоту скажем в 24 МГц.
Тем более, что в некоторых ситуациях частота может быть и не 24 МГц совсем, например при тактировании от LRC.

Понятное дело, что для того, чтобы из PLL выходила нужная частота, нужно знать какая у него опорная частота, чтобы потом соответствующим образом подстроить его делители.

Это ни на что не влияет, проблема не в софте, а в железе.

Подтяжкой можно различить только между Low-speed и Full/High-speed устройствами, собственно для попадания на High-speed нужно сделать дополнительное согласование, потом эта подтяжка вообще отлючается, т.к. тут уже линии нагружаются иначе.

Подпись автора

水Mizu-DEC JLtech since 22.06.2019

по моему, он без флеша. нужно внешнюю вешать.