USMI

Объявление

12/06/2025 (Administration) - Spamming for the purpose of boosting messages will be punished with a ban. Спам с целью накрутки сообщений будет караться баном.

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.


Вы здесь » USMI » MCU, SoC, CPU Микроконтроллеры » JL SoC. 杰理芯片


JL SoC. 杰理芯片

Сообщений 1781 страница 1800 из 1857

1781

Всем привет! Ранее я писал, что с помощью SDK мне удалось скомпилировать рабочую прошивку для Joyo, стараясь сохранить функциональность максимально близкой к оригинальному устройству. Хорошие новости: устройство работает на ПК и портативных устройствах (после патча для ограничения потребляемого тока), но возникла одна трудность, которую пока не могу решить.

При включенном микрофонном канале примерно через 40 секунд появляется периодический шум, который накладывается на входной сигнал. Если канал микрофона отключен, звук чистый.

Характеристики шума:
- Цикл ~2.7 секунды (2340мс шум + 375мс тишина)
- Внутри цикла импульсы по ~10мс с интервалом ~21мс

Прилагаю изображение спектрального анализа и пример аудиофайла с записью шума.

https://upforme.ru/uploads/001b/ca/8a/329/t193789.png

Перепробовал уже всё: отключал watchdog, сканирование батареи, AUX, LED, LOOP_DETECT_REGISTER, менял приоритеты прерываний, искал таймеры на 40 секунд... не могу найти причину этого шума.

Подозреваю, что какой-то системный периодический task конфликтует с аудиопотоком, но не могу его найти в SDK, чтобы отключить.

У кого-нибудь был похожий опыт с чипами JieLi?

Полный проект на моём GitHub и подробности на блоге.

Спасибо.

1782

Отруби таскер вообще. Это может быть какая то либа.

jpregiati написал(а):

Всем привет! Ранее я писал, что с помощью SDK мне удалось скомпилировать рабочую прошивку для Joyo, стараясь сохранить функциональность максимально близкой к оригинальному устройству. Хорошие новости: устройство работает на ПК и портативных устройствах (после патча для ограничения потребляемого тока), но возникла одна трудность, которую пока не могу решить.

При включенном микрофонном канале примерно через 40 секунд появляется периодический шум, который накладывается на входной сигнал. Если канал микрофона отключен, звук чистый.

Характеристики шума:
- Цикл ~2.7 секунды (2340мс шум + 375мс тишина)
- Внутри цикла импульсы по ~10мс с интервалом ~21мс

Прилагаю изображение спектрального анализа и пример аудиофайла с записью шума.

Перепробовал уже всё: отключал watchdog, сканирование батареи, AUX, LED, LOOP_DETECT_REGISTER, менял приоритеты прерываний, искал таймеры на 40 секунд... не могу найти причину этого шума.

Подозреваю, что какой-то системный периодический task конфликтует с аудиопотоком, но не могу его найти в SDK, чтобы отключить.

У кого-нибудь был похожий опыт с чипами JieLi?

Полный проект на моём GitHub и подробности на блоге.

Спасибо.

А не из вне этот шум?
Какая версия сдк?

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

USMicro® 2026©

1783

BIOS написал(а):

А не из вне этот шум?

Шум идёт не извне, это сигнал, который попадает в ЦАП и накладывается на звук с USB. Возможно, он идёт по тому же контакту, что и микрофон, или это RF-сканирование (Bluetooth/FM), запускаемое библиотеками, мне не удалось его отключить, так что, скорее всего, оно автоматическое и не настраивается.

BIOS написал(а):

Какая версия сдк?

SDK 2.6.2.

Актуальная ссылка на GitHub

1784

Используй последний AC692x_SDK_release_V2.6.3. У меня на гитхабе она есть.
https://github.com/USMI-Tech/AC692X-SDK
Попробуй прошить для эксперимента чистую не настроенную прошивку. Я думаю это где то баг в сдк, или мультиплекс контактов. А что по схеме там?

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

USMicro® 2026©

1785

BIOS написал(а):

Используй последний AC692x_SDK_release_V2.6.3. У меня на гитхабе она есть.
https://github.com/USMI-Tech/AC692X-SDK
Попробуй прошить для эксперимента чистую не настроенную прошивку. Я думаю это где то баг в сдк, или мультиплекс контактов. А что по схеме там?

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

    USMicro(R) (C)2025

Привет BIOS, Мой чип AC6926A4. Я попробовал все версии SDK, проблема воспроизводится на всех, включая 2.6.3.
Я думаю, что noise burst это не баг в SDK, а намеренное ограничение, введённое JieLi непосредственно в скомпилированные библиотеки. По аналогии с демо-версиями VST/DAW плагинов, где после определённого времени добавляется шум, чтобы предотвратить коммерческое использование без лицензии.
В данный момент я пытаюсь сделать reverse engineering библиотек, следуя вот этому примеру. Пока без особых успехов, ключевые части SDK скомпилированы под проприетарную архитектуру PI32, которую стандартными инструментами не разобрать.
Предполагаю, что ограничение снимается после официального обращения в JieLi и получения файла .lic для компиляции, стандартная практика для коммерческих партнёров.

1786

jpregiati написал(а):

Привет BIOS, Мой чип AC6926A4. Я попробовал все версии SDK, проблема воспроизводится на всех, включая 2.6.3.
Я думаю, что noise burst это не баг в SDK, а намеренное ограничение, введённое JieLi непосредственно в скомпилированные библиотеки. По аналогии с демо-версиями VST/DAW плагинов, где после определённого времени добавляется шум, чтобы предотвратить коммерческое использование без лицензии.
В данный момент я пытаюсь сделать reverse engineering библиотек, следуя вот этому примеру. Пока без особых успехов, ключевые части SDK скомпилированы под проприетарную архитектуру PI32, которую стандартными инструментами не разобрать.
Предполагаю, что ограничение снимается после официального обращения в JieLi и получения файла .lic для компиляции, стандартная практика для коммерческих партнёров.

Привет. Дело в том что у меня есть эти чипы и такого бага нет, эти СДК, на них массово производили модули. Тот же BT201. Возьмите голую плату с чипом, например тот же BT 201, там стоит AC6925A.

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

USMicro® 2026©

1787

Проверил сейчас с блютузом, подключил - поиграл, остановил, прождал более 40 секунд. Нет проблем.

jpregiati написал(а):

При включенном микрофонном канале примерно через 40 секунд появляется периодический шум, который накладывается на входной сигнал. Если канал микрофона отключен, звук чистый.

Характеристики шума:
- Цикл ~2.7 секунды (2340мс шум + 375мс тишина)
- Внутри цикла импульсы по ~10мс с интервалом ~21мс

А микрофон может не микрофон вовсе? Попробуй использовать линейный вход или даже AMUX что бы без оцифровки  мика. Даже интересно стало попробовать, А когда вы включаете мик, или просто включили в СДК и все? Я хочу повторить этот баг, есть ссылка именно на Ваш сдк? что бы я залил на плату и проверил.

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

USMicro® 2026©

1788

jpregiati написал(а):

Привет BIOS, Мой чип AC6926A4. Я попробовал все версии SDK, проблема воспроизводится на всех, включая 2.6.3.
Я думаю, что noise burst это не баг в SDK, а намеренное ограничение, введённое JieLi непосредственно в скомпилированные библиотеки. По аналогии с демо-версиями VST/DAW плагинов, где после определённого времени добавляется шум, чтобы предотвратить коммерческое использование без лицензии.
В данный момент я пытаюсь сделать reverse engineering библиотек, следуя вот этому примеру. Пока без особых успехов, ключевые части SDK скомпилированы под проприетарную архитектуру PI32, которую стандартными инструментами не разобрать.
Предполагаю, что ограничение снимается после официального обращения в JieLi и получения файла .lic для компиляции, стандартная практика для коммерческих партнёров.

И все  же нет, я думаю тут просто где то мультиплекс или ещё что накручено в софте.

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

USMicro® 2026©

1789

А есть ли какая то таблица кодов для ИК пульта которые получает МК?

1790

BIOS написал(а):

jpregiati написал(а):

    Привет BIOS, Мой чип AC6926A4. Я попробовал все версии SDK, проблема воспроизводится на всех, включая 2.6.3.
    Я думаю, что noise burst это не баг в SDK, а намеренное ограничение, введённое JieLi непосредственно в скомпилированные библиотеки. По аналогии с демо-версиями VST/DAW плагинов, где после определённого времени добавляется шум, чтобы предотвратить коммерческое использование без лицензии.
    В данный момент я пытаюсь сделать reverse engineering библиотек, следуя вот этому примеру. Пока без особых успехов, ключевые части SDK скомпилированы под проприетарную архитектуру PI32, которую стандартными инструментами не разобрать.
    Предполагаю, что ограничение снимается после официального обращения в JieLi и получения файла .lic для компиляции, стандартная практика для коммерческих партнёров.

И все  же нет, я думаю тут просто где то мультиплекс или ещё что накручено в софте.

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

    USMicro(R) (C)2025

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

BIOS написал(а):

Проверил сейчас с блютузом, подключил - поиграл, остановил, прождал более 40 секунд. Нет проблем.
jpregiati написал(а):

    При включенном микрофонном канале примерно через 40 секунд появляется периодический шум, который накладывается на входной сигнал. Если канал микрофона отключен, звук чистый.

    Характеристики шума:
    - Цикл ~2.7 секунды (2340мс шум + 375мс тишина)
    - Внутри цикла импульсы по ~10мс с интервалом ~21мс

А микрофон может не микрофон вовсе? Попробуй использовать линейный вход или даже AMUX что бы без оцифровки  мика. Даже интересно стало попробовать, А когда вы включаете мик, или просто включили в СДК и все? Я хочу повторить этот баг, есть ссылка именно на Ваш сдк? что бы я залил на плату и проверил.

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

    USMicro(R) (C)2025

Насчёт других пинов, к сожалению, я не могу этого сделать, так как плата уже готовая, это коммерческий продукт, который я пытаюсь модифицировать. Схему изменить нельзя.

Уточняю поведение шума: он появляется только когда на вход поступает сигнал (гитара или бас). Если входного сигнала нет, выход DAC чистый. Возможно, это связано с обработкой сигнала микрофонного канала, но я не уверен.

Вот путь от входного джека к буферу с единичным усилением:

https://upforme.ru/uploads/001b/ca/8a/329/t572041.png

А вот сигнал, поступающий на пин PA0/MIC:

https://upforme.ru/uploads/001b/ca/8a/329/t59975.png

Вот SDK, с которым мне удалось запустить плату.
Если сможешь воспроизвести проблему и направить меня к решению, буду очень благодарен!

1791

WinD написал(а):

А есть ли какая то таблица кодов для ИК пульта которые получает МК?

Какой именно?
Во всех JL по дефолту используют NEC 00FF user code. Можно отснифить пульт, лучше делать самим JL, используя уже существующий драйвер. добавить принты, и получить через уарт нормальные команды так как их воспринимает проц.
Почему так - например я использовал транзистор тестер с ик декодером - он говорит команды почему то в отзеркаленном виде.

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

USMicro® 2026©

1792

jpregiati написал(а):

Вот SDK, с которым мне удалось запустить плату.
Если сможешь воспроизвести проблему и направить меня к решению, буду очень благодарен!

Смогу только через неделю, а то не дома уже.

jpregiati написал(а):

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

Насчёт других пинов, к сожалению, я не могу этого сделать, так как плата уже готовая, это коммерческий продукт, который я пытаюсь модифицировать. Схему изменить нельзя.

Уточняю поведение шума: он появляется только когда на вход поступает сигнал (гитара или бас). Если входного сигнала нет, выход DAC чистый. Возможно, это связано с обработкой сигнала микрофонного канала, но я не уверен.

Вот путь от входного джека к буферу с единичным усилением:

А вот сигнал, поступающий на пин PA0/MIC:

Вот SDK, с которым мне удалось запустить плату.
Если сможешь воспроизвести проблему и направить меня к решению, буду очень благодарен!

Вот похоже не мультиплекс, или ещё чего...  Посмотрел PA0/MIC: по даташиту только мик или уарт. Нет мультиплекса.
Я бы для начала попробовал бы поотключать все неиспользуемые пины, сделать их в высокий импеданс и выход, прописать в маине, или павер ините. Имейте в виду что у чипа не 26 выводов на самом деле. А 60 как минимум.
portA/B/C/D 0-15/.(portd частично занят внутренней флешкой). Группу Д не трогаем короче.
Или пойдем другим путем, а в ориге такого нет?
Если нет, значить нужно смотреть путь всего микрофона, ADC-затем оно идет в буфер, и далее.
Я как то микрофон и не тестил на 692. Только с A2DP, не более. А вот AUX тестил, там проблем нет таких.

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

USMicro® 2026©

1793

BIOS написал(а):

jpregiati написал(а):

    Вот SDK, с которым мне удалось запустить плату.
    Если сможешь воспроизвести проблему и направить меня к решению, буду очень благодарен!

Смогу только через неделю, а то не дома уже.
jpregiati написал(а):

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

    Насчёт других пинов, к сожалению, я не могу этого сделать, так как плата уже готовая, это коммерческий продукт, который я пытаюсь модифицировать. Схему изменить нельзя.

    Уточняю поведение шума: он появляется только когда на вход поступает сигнал (гитара или бас). Если входного сигнала нет, выход DAC чистый. Возможно, это связано с обработкой сигнала микрофонного канала, но я не уверен.

    Вот путь от входного джека к буферу с единичным усилением:

    А вот сигнал, поступающий на пин PA0/MIC:

    Вот SDK, с которым мне удалось запустить плату.
    Если сможешь воспроизвести проблему и направить меня к решению, буду очень благодарен!

Вот похоже не мультиплекс, или ещё чего...  Посмотрел PA0/MIC: по даташиту только мик или уарт. Нет мультиплекса.
Я бы для начала попробовал бы поотключать все неиспользуемые пины, сделать их в высокий импеданс и выход, прописать в маине, или павер ините. Имейте в виду что у чипа не 26 выводов на самом деле. А 60 как минимум.
portA/B/C/D 0-15/.(portd частично занят внутренней флешкой). Группу Д не трогаем короче.
Или пойдем другим путем, а в ориге такого нет?
Если нет, значить нужно смотреть путь всего микрофона, ADC-затем оно идет в буфер, и далее.
Я как то микрофон и не тестил на 692. Только с A2DP, не более. А вот AUX тестил, там проблем нет таких.

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

    USMicro(R) (C)2025

В оригинальной прошивке такой проблемы нет.

Один из моих предыдущих опытов заключался в отключении всех неиспользуемых функций в коде, но я не подумал о том, что соответствующие пины могли оставаться активными. Попробую обновить функцию set_port_init() следующим образом, оставив активными только PA0/MIC, PB0/PB1/PB2 (кнопки), PC4/PC5 (LED), DAC и USB, как в оригинальной прошивке устройства:

Код:
static void set_port_init()
{
#ifndef UART_TXPA3_RXPA4
    JL_PORTA->DIR |=  BIT(3);
    JL_PORTA->PD  &= ~BIT(3);
    JL_PORTA->PU  &= ~BIT(3);
#endif

    JL_PORTA->DIR |=  BIT(0);
    JL_PORTA->PD  &= ~BIT(0);
    JL_PORTA->PU  &= ~BIT(0);

    JL_PORTA->DIR &= ~(BIT(1) | BIT(2));
    JL_PORTA->PD  &= ~(BIT(1) | BIT(2));
    JL_PORTA->PU  &= ~(BIT(1) | BIT(2));

    JL_PORTB->DIR &= ~(BIT(3)|BIT(4)|BIT(5)|BIT(6)|BIT(7)|
                       BIT(8)|BIT(9)|BIT(10)|BIT(11)|BIT(12)|
                       BIT(13)|BIT(14)|BIT(15));
    JL_PORTB->PD  &= ~0xFF00;
    JL_PORTB->PU  &= ~0xFF00;

    JL_PORTC->DIR &= ~(BIT(0)|BIT(1)|BIT(2)|BIT(3)|BIT(6)|BIT(7)|
                       BIT(8)|BIT(9)|BIT(10)|BIT(11)|BIT(12)|
                       BIT(13)|BIT(14)|BIT(15));
    JL_PORTC->PD  &= ~0xFF0F;
    JL_PORTC->PU  &= ~0xFF0F;

#ifndef UART_USBP_USBM
    usb_2_io();
    USB_DP_PU(0);
    USB_DP_PD(0);
    USB_DP_DIR(1);
#endif
}

DACR и DACL (пины 29 и 30) являются аналоговыми выходами и управляются драйвером DAC напрямую, поэтому их трогать не нужно.

Вот оригинальная прошивка, если хочешь протестировать.

1794

День добрый!
Провожу эксперименты с платой от наушников RB-01_AC6955F_V2.0
Собрал донгл на Arduino UNO R3,  удалил резистора 200 ом (на плате обвел), и на прямую подкинул
D+ на микросхему. После подключения к USB опреденяется как BR23, непосредственно в BOOT режим заходит после нажатия кнопки
включения наушников (PB1). Слил прошивку. Вопрос такой, как поменять mac адрес? Сам мак адрес знаю, как найти в прошивке? https://upforme.ru/uploads/001b/ca/8a/334/t707929.jpg

1795

Нашел дамп AC6955F, там mac указан где находится, в своем дампе не могу найти.

1796

Хочу поделиться результатами двух экспериментов, которые я провёл после ваших советов.

1. Отключение неиспользуемых пинов
По вашему совету попробовал перевести все неиспользуемые пины в высокий импеданс или в output, оставив активными только PA0/MIC, PB0/PB1/PB2 (кнопки), PC4/PC5 (LED), DAC и USB:

Код:
JL_PORTA->DIR &= ~(BIT(1) | BIT(2));
JL_PORTA->PD  &= ~(BIT(1) | BIT(2));
JL_PORTA->PU  &= ~(BIT(1) | BIT(2));

JL_PORTB->DIR &= ~(BIT(3)|BIT(4)|BIT(5)|BIT(6)|BIT(7)|
                   BIT(8)|BIT(9)|BIT(10)|BIT(11)|BIT(12)|
                   BIT(13)|BIT(14)|BIT(15));
JL_PORTB->PD  &= ~0xFF00;
JL_PORTB->PU  &= ~0xFF00;

JL_PORTC->DIR &= ~(BIT(6)|BIT(7)|BIT(8)|BIT(9)|BIT(10)|
                   BIT(11)|BIT(12)|BIT(13)|BIT(14)|BIT(15));
JL_PORTC->PD  &= ~0xFF00;
JL_PORTC->PU  &= ~0xFF00;

Результат: шум остался.

2. Переназначение пинов (IO remapping)
Изучив User Manual AC692X, я обнаружил, что PA0 имеет несколько функций мультиплексирования: MIC, UART0RXB, PLNK_DAT0, PWMCH0H, SEG0. Я предположил, что один из этих сигналов мог конфликтовать с MIC каналом. Проверил конфигурацию UART0 в регистре IOMAP->CON0 и переназначил его на PA5/PA6, добавив в функцию set_port_init():

Код:
JL_IOMAP->CON0 &= ~(BIT(7) | BIT(6));

Результат: шум остался.

В итоге, после анализа всего исходного кода SDK, я не нашёл источник проблемы в открытой части.

1797

jpregiati написал(а):

Хочу поделиться результатами двух экспериментов, которые я провёл после ваших советов.

1. Отключение неиспользуемых пинов
По вашему совету попробовал перевести все неиспользуемые пины в высокий импеданс или в output, оставив активными только PA0/MIC, PB0/PB1/PB2 (кнопки), PC4/PC5 (LED), DAC и USB:

Попробуйте это прошить.
https://drive.google.com/file/d/1iKP_6e … sp=sharing

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

USMicro® 2026©

1798

Привет всем.

Хочу поделиться своим опытом и попросить помощи.

У меня есть чип JieLi AC6925B (снят с готового Bluetooth-устройства). Я смог перевести его в режим BR21 UBOOT (USB определяется как «BR21 UBOOT DEVICE 1.00») с помощью внешнего генератора сигнала(STM32)

Далее пытался прошить его через стандартные инструменты SDK/ISD, но постоянно получал ошибку:
"no_isd_file"

Я перепробовал разные версии SDK для серии AC692x — результат везде одинаковый.

После этого попробовал патч, который выкладывался на этом форуме. С ним ситуация изменилась:

- ошибка "no_isd_file" исчезла ✔
- устройство стало корректно определять флеш-память ✔
- появился доступ к операциям ✔

Но возникла новая проблема:
Ошибка размера прошивки

При попытке прошивки получаю ошибку, что размер прошивки превышает размер флеша (512K), хотя я максимально упростил проект — оставил буквально 5 MP3 файлов, без лишнего.

Не совсем понимаю:

- где именно происходит переполнение
- как правильно контролировать размер (разделы / ресурсы / конфиг)
Проблема с SDK.EXE

Также есть проблема с запуском SDK.EXE:

На Windows 10 x64 программа не запускается и выдает ошибку (точный текст не помню), что-то вроде:

- несовместимость архитектуры
- или «недостаточная разрядность / спецификация»

Возможно, это связано с тем, что программа:

- 32-битная?
- или требует старых библиотек / среды?
Вопросы

1. Почему даже минимальная прошивка (несколько MP3) превышает 512K?
2. Как правильно уменьшить размер (или настроить разделы)?
3. Как запустить SDK.EXE на Windows 10 x64?
4. Может ли это быть связано с самим патчем?

Буду очень благодарен за любую помощь.

Спасибо!

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

"JieLi, if your firmware is closed and your pathways unseen, are you an intelligence or just a carefully gated circuit of borrowed intention?"

1799

WinD написал(а):

А есть ли какая то таблица кодов для ИК пульта которые получает МК?

В общем изучил несколько SDK, у меня 6955 задача которую хотел решить это общение stm32 и 6955 для управления мультимедиа. Сейчас задачу решаю немного тупо - через адкей и 3 вывода мк с задаными резисторами. Stm слушает can шину авто, и по паттерну ловит нажатие кнопок на руле или морде мультимедиа, и дёргает соответствующие ноги для управления. Но хотелось бы интегрировать чуть глубже. Подопотный модуль - xy-wrbt с колёсиком. Нашёл в разборках ИК приёмник, запаял. Подключил к ноге out и посмотрел что ловит и на что реагирует ac6955. Оказалось что он достаточно всеядный, срабатывает почти на любой пульт что есть у меня дома. Протокол действительно NEC записал эти команды и попытался их эмулировать напрямую, не работает. Думаю проблема в коде стм. Буду продолжать эксперемент.
Также интересно изучить как можно сконфигурировать этот ac6955, sdk на него не нашёл. Возможно ли это вообще?

1800

WinD написал(а):

Также интересно изучить как можно сконфигурировать этот ac6955, sdk на него не нашёл. Возможно ли это вообще?

Самый простой - таки имитировать нажатия ик пульта, (сначала поработать с реальным пультом, посмотреть что бы все работало, там нужно раксскоментировать строку кода с фильтром юзер кода) отснифить что там читает JL на самом деле - и эмулировать этот tsop 38 КГц, эмулятор пульта, и там сигнал постоянно высокий, я возился с этой темой.
Следующий простой -  заюзать ADKEY ADC или вообще отдельно на каждую ногу - по команде, те обычный GPIO...

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

USMicro® 2026©


Вы здесь » USMI » MCU, SoC, CPU Микроконтроллеры » JL SoC. 杰理芯片