CH582M (СH581, CH582, СH583)

[pecherskih]

Коллеги, добрый день. Как то я обещал поделиться результатами работы с проводным бутлоадером. В связи с чем и выкладываю результаты. На данный момент удалось запустить обновление прошивки по протоколу UART. Однако заработало не всё. Проблема в верификации залитой прошивки. При записи на все фреймы стек отвечает ОК. Т.е. ошибок не происходит. Если подать команду обновления, то блок удачно запускается с новой прошивкой. Но если сделать верификацию, она вылетает с ошибкой. Причем битыми указываются одни и те же 2-3 фрейма, вне зависимости от платы отладки. На данный момент я не смог понять причину. По воздуху обновление прошивки и верификация проходят без ошибок. Так что думаю проблема где то у меня.


OnlyUpdateApp
Для обновления прошивки контроллера существует два способа. Первый способ (OnlyUpdateApp) используется для контроллеров с малым объемом внутреннего FLASH. Это CH581F с памятью в 192 кБайтов. Вся память делится на 4 части. В первой располагается вектор перехода (JumpIAP) на бутлоадер IAP. Во второй части (Peripheral) располагается приложение пользователя, которое и надо обновлять. В третьей части памяти находится сам бутлоадер IAP (In-Application Programming). Ну и наконец, в последней части находится библиотека стека BLE.

JumpIAP	Peripheral	IAP	LIB
4k	44k	16k	128k
0кB			192кB

При подаче питания на контроллер, управление передается по нулевому адресу программы, где лежит команда (JumpIAP) перехода на IAP. После этого перехода внутри IAP анализируется нужно производить обновление или нет. Если обновление не нужно, тогда управление передается в сегмент Peripheral и дальше исполняется программа пользователя. Если же обновлять прошивку нужно, управление остается в сегменте IAP и используя стек BLE из части LIB, контроллер обновляет прошивку пользователя в сегменте Peripheral. Во время обновления функции самой прошивки Peripheral не доступны. Для создания обобщенной прошивки, используются 3 отдельных проекта из папки WCH\ch583-main\EVT\EXAM\BLE с общим названием OnlyUpdateApp. Четвертым файлом является файл стека CH58xBLE_ROM. Объединяются 4 HEX файла при помощи приложения AssemblingFileTool, находящегося в папке WCH\ch583-main\Android Tool. На андроиде, для обновления прошивки «по-воздуху», используется приложение CH583 OTA Tool, находящегося в WCH\ch583-main\Android Tool\OTA Tool.


BackupUpgrade
Для процессоров с большим объемом памяти, таким как CH582/583, используется другой способ обновления. В этом, втором способе, обновляется не только
приложение пользователя, но также сама BLE библиотека. Кроме того, при этом способе сохраняется работоспособность пользовательского кода. Здесь FLASH память так же делится на 4 части. В первой (JumpIAP) так же лежит команда перехода на IAP. Во второй части лежат приложение пользователя и библиотека BLE. Четвертая часть памяти остается пустой. Сюда будет записываться новая прошивка. Ну и в последней части памяти находится сам IAP.

JumpIAP	Peripheral + LIB	Reserve	IAP
4k	216k	216k	12k
0кB			448кB

При подаче питания на контроллер, также как и в первом случае, управление передается по нулевому адресу программы, где лежит команда (JumpIAP) перехода на IAP. Далее бутлоадер IAP анализирует надо ли ему включаться в работу или нет. Если нет, тогда управление передается приложению пользователя. Одной из задач этого приложения является заполнение пустого пространства FLASH памяти новой прошивкой. Если загрузка новой прошивки прошла успешно, выставляется флаг события и подается команда перезагрузки. В этом случае IAP копирует новое приложение пользователя и BLE библиотеку из третьего в второй сегмент FLASH памяти, снимает флаг события и перезагружает процессор. Для создания обобщенной прошивки, используются 3 отдельных проекта из папки WCH\ch583-main\EVT\EXAM\BLE с общим названием BackupUpgrade. Объединяются 3 HEX файла при помощи того же приложения AssemblingFileTool. Для обновления прошивки «по-воздуху», используется приложение CH583 OTA Tool, как и в первом случае. Для меня интересен второй способ обновления, который позволяет не терять связь с пользовательской прошивкой. Рассмотрим команды, которые в нем применяются.


Команды bootloader-a
При работе со стеком, обновление прошивки происходит также как и при любой другой задаче, через команды стека. Мы не
можем напрямую прочитать или записать участок FLASH памяти напрямую. Для этого применяются 5 команд. Рассмотрим их.
1. IAP_INFO – команда запроса конфигурации устройства, где 0х84 – ID команды,
0х12 – длина посылки после текущего байта. Вот как выглядит полная команда.
84 12 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
В ответ контроллер отправляет посылку со своей конфигурацией. Например такую:
02 00 60 03 00 00 10 83 00 44 00 20 B8 44 00 20 34 0B 00 20
0х02-второй вариант обновления (с BLE стеком), 0х00036000 = 216к размер памяти под
новую прошивку, 0х1000 – размер сегмента памяти, 0х0083 – процессор ch583
2. IAP_ERASE – команда стеку на стирание сегментов памяти, где 0х81 – ID команды,
0х1000 – начальный адрес сегментов, 0х0025=37 сегментов памяти надо стереть.
81 00 00 01 25 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
В ответ стек отправляет нулевой байт, в случае успеха или ненулевой байт ошибки.
3. IAP_PROM – команда записи данных во FLASH. Она состоит из заголовка и данных.
80 F0 00 01
0х80 – ID команды, 0хF0 = 240 длина блока данных, 0х1000 – адрес блока памяти.
После этой команды передается блок данных длиной 240 байт.
4. IAP_VERIFY – команда верификации. Она очень похожа на команду IAP_PROM,
отличается только ID заголовком, который равен 0х82.
5. IAP_END – команда успешного окончания заливки новой прошивки. Вот она:
83 12 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Она похожа на команду IAP_INFO. После её получения выставляется флаг новой
прошивки и дается команда перезагрузки процессора.

 

[pvvx]

Это очередной кошмар WCH.
Вместо того, чтобы сменить адрес отображения Flash, её переписывают по десять раз.
(Похоже надо делать свою OTA, а на WCH забить)
И возникает ещё один вопрос - это всё значит, что OTA на WCH небезопасная?

 

[DanilinSA]

Подскажите пожалуйста, извлечь прошивку из чипа CH582F вообще реально?
Через команды бутлоадера например?
Или через запись в RAM программы, ее запуск и выгрузка прошивки через доступный интерфейс?
Доступен USB и USART.

 

[pecherskih]

Подскажите пожалуйста, извлечь прошивку из чипа CH582F вообще реально?
Через команды бутлоадера например?
Или через запись в RAM программы, ее запуск и выгрузка прошивки через доступный интерфейс?
Доступен USB и USART.

Лично я не подскажу. Не было такой задачи. Могу сказать только что в режиме Debug у меня не получается увидеть всю память. Может что не так делаю, может заблокирована. Если найдете какое то решение - напишите, всем будет интересно.

 

[pvvx]

В этом случае IAP копирует новое приложение пользователя и BLE библиотеку из третьего в второй сегмент FLASH памяти, снимает флаг события и перезагружает процессор.

Зачем копировать и переписывать по десять раз Flash?
Почему нет переключения начального адреса отображения Flash в адресном пространстве CPU?
Не хватило пару бит у дешифратора адреса? И тут зажали пару транзисторов?

 

[DanilinSA]

Подскажите по CH852F. Пока в этой архитектуре новичок, многое не понятно.
Беру отладку CH852F. Цепляю по SWD к ней отладчик WCH-LinkRV.
Собираю в MounRiver Studio простейший пример "broadcaster". Работает.

Но мне интересен именно внутренний флеш. И тут начинается веселье.
1) Прошиваю чип. Включаю SWD интерфейс.
2) Запускаю OpenOCD.
3) Весь чип доступен. Флеш и ОЗУ читается и дампится. Но .. начало флеша забита постоянным патерном.

> mdw 0x00000010 100
0x00000010: f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9
0x00000030: f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9
0x00000050: f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9
0x00000070: f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9
0x00000090: f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9
0x000000b0: f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9
0x000000d0: f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9
0x000000f0: f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9
0x00000110: f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9
0x00000130: f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9
0x00000150: f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9
0x00000170: f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9
0x00000190: f3f9bda9 f3f9bda9 f3f9bda9 f3f9bda9

И так до адреса 0x00002000. Далее все совпадает с HEX файлом прошивки.
Соответственно и в дампе аналогично.
Такое чувство, что часть прошивки закрыта для чтения. Сам шил во флеш без галок защиты.
3) Запускаю MounRiver Studio. Без перезаливки во флеш даю комманду "debug"
Видим, как стартует OpenOCD. Встаем на код "startup_583.S". Логично. На

00001cc0: auipc gp,0x20001

Цепляемся на 4444 порт отладчика. Видим:

Open On-Chip Debugger
> mdw 0x00000010 100
0x00000010: 20000580 f5f9bda9 20000094 00000000 00000000 20000096 20000098 00000000
0x00000030: 00000000 2000009a 00000000 2000009c 00000000 2000009e 200000a0 200000a2
0x00000050: 200000a4 200000a6 200000a8 200000aa 200000ac 200000ae 200000b0 200000b2
0x00000070: 200000b4 200000d0 200000b8 200000ba 200000bc 200000be 200000c0 200000c2
0x00000090: 200000c4 a001a001 a001a001 a001a001 a001a001 a001a001 a001a001 a001a001
0x000000b0: a001a001 a001a001 a001a001 a001a001 a001a001 a001a001 1141a001 00efc606
0x000000d0: bff53930 400017b7 03000713 02e78823 37174785 2b230000 00737cf7 11413020
0x000000f0: 46014681 45114581 2b5dc606 400027b7 83234711 f7b780e7 a703e000 9b6dd107
0x00000110: d0e7a823 d107a703 a8239b5d 0073d0e7 00011050 40b20001 80820141 46811141
0x00000130: 45814601 c6064511 27b72ba5 47114000 80e78323 400017b7 02e7c703 04e7c683
0x00000150: 0387d783 77136611 e6930ff7 e5630036 9b7100c7 00176713 400017b7 05700593
0x00000170: 04b78023 fa800613 04c78023 00010001 02078223 02e78723 04d78723 04b7c703
0x00000190: 02076713 04e785a3 04078023 e000f737

Т.е. начало флеша прекрасно видится и соответствует HEX для прошивки.

Для чистоты эксперимента отладчик OpenOCD и конфигурационный файл для него одинаков для "ручного запуска" и MounRiver Studio. Но MounRiver Studio видит начало флеша, а я "в рукопашную" - нет. Почему? Что происходит?
Штатный прошивальщик "по умолчанию" включает защиту для начал флеша? А MounRiver Studio снимает защиту? Или что-то не понимаю?

 

[pecherskih]

Подскажите по CH852F. Пока в этой архитектуре новичок, многое не понятно.
Беру отладку CH852F. Цепляю по SWD к ней отладчик WCH-LinkRV.
Собираю в MounRiver Studio простейший пример "broadcaster". Работает.

Но мне интересен именно внутренний флеш. И тут начинается веселье.
1) Прошиваю чип. Включаю SWD интерфейс.
2) Запускаю OpenOCD.
3) Весь чип доступен. Флеш и ОЗУ читается и дампится. Но .. начало флеша забита постоянным патерном.

И так до адреса 0x00002000. Далее все совпадает с HEX файлом прошивки.
Соответственно и в дампе аналогично.
Такое чувство, что часть прошивки закрыта для чтения. Сам шил во флеш без галок защиты.
3) Запускаю MounRiver Studio. Без перезаливки во флеш даю комманду "debug"
Видим, как стартует OpenOCD. Встаем на код "startup_583.S". Логично. На
Цепляемся на 4444 порт отладчика. Видим:

Т.е. начало флеша прекрасно видится и соответствует HEX для прошивки.

Для чистоты эксперимента отладчик OpenOCD и конфигурационный файл для него одинаков для "ручного запуска" и MounRiver Studio. Но MounRiver Studio видит начало флеша, а я "в рукопашную" - нет. Почему? Что происходит?
Штатный прошивальщик "по умолчанию" включает защиту для начал флеша? А MounRiver Studio снимает защиту? Или что-то не понимаю?

Привет. Да тут есть какие то непонятки. Китайцы что то накрутили по-моему. Вот пример. Есть прошивка длиной 0х29A30 (слева). В отладчике MounRiver Studio в окне Memory мы видим что после данных идут 0хFF(в центре). Но как только заканчивается текущий сегмент, мы видим, что FLASH заполнена непонятным постоянным патерном. И так продолжается до конца памяти (0х80000). Поэтому посмотреть что там лежит в EEPROM-е (0х70000-0х80000) не представляется возможным.

 

[pecherskih]

Кстати, читали мои последние статьи? Вторая описывает работу с контроллером CH582.

BLE под микроскопом (ATTы GATTы...) Продолжение

BLE под микроскопом. (ATTы GATTы...) Продолжение В этой статье мы будем разбираться с таблицей атрибутов. С её структурой и наполнением. Таблица размещается в глубинах стека и каждая её строка — это...

habr.com

BLE под микроскопом. WCH forever :-)

Введение Итак, приступим. Сразу хочу рассказать о двух русскоязычных площадках на которых мы с коллегами уже активно обсуждаем эти чипы. Вот первая , а здесь вторая площадка, которую я и создал :-)...

habr.com

Сейчас разбираюсь с RTC. Наступил на вот какие грабли. При старте инициализируются часики командой RTC_InitTime(), и далее по BLE я могу запросить текущее значение часов командой RTC_GetTime(). Но если мне надо установить новое значение часов через смартфон, процессор перезагружается. Как я понял, потому что сбиваются таймауты работы по BLE. Вопрос. Кто-нибудь сталкивался с этой проблемой и как её решил. Есть обходные пути, но слишком корявые. Может есть какой то правильный способ?

 

[pvvx]

Может есть какой то правильный способ?

Любой аппаратный счетчик ведет отсчет относительно чего-то. В Linux обычно от начала 1970г... В WiFi у AP timestamp в 1 us относительно старта (включения питания)...
Используйте своё смешение, аналогично GMT+X. Его и меняйте.

 

[pvvx]

Что происходит?

Не копался, но по аналогии с другими SoC - специфика инициализации контроллера отображения памяти/кэша, связанная с "защитами" по сегментам.

 

[pvvx]

Да тут есть какие то непонятки. Китайцы что то накрутили по-моему.

А у всех CH MCU Flash разве не SPI? В адресное пространство отображается путем работы спец. контроллера, читающего кусочками в "кэш" с QSPI Flash кристалла? Тогда как инициализировали эту "кеш" так и будет отображать.
В некоторых вариантах у WCH MCU, что на 144MHz и боле тупо стоит дублирующая RAM, в которую по старту переписывается код из SPI-Flash.

 

[pvvx]

Подскажите по CH852F.

WCH CH583/CH582/CH581 Datasheet V1.3: 3.4.3 Physical memory protection unit, PMP.

 

[DanilinSA]

Привет. Да тут есть какие то непонятки. Китайцы что то накрутили по-моему. Вот пример. Есть прошивка длиной 0х29A30 (слева). В отладчике MounRiver Studio в окне Memory мы видим что после данных идут 0хFF(в центре). Но как только заканчивается текущий сегмент, мы видим, что FLASH заполнена непонятным постоянным патерном. И так продолжается до конца памяти (0х80000). Поэтому посмотреть что там лежит в EEPROM-е (0х70000-0х80000) не представляется возможным.

Тут как-раз ничего загадочного нет. Работает защита от чтения. Все операции чтения флеша выдают значение - затычку. Самое неприятное - CPU то-же не видит.

Вот мое исследование защиты (информация не полная, возможно ошибочная. нужно проверять ):
1) Защита врубается исключительно при активации SWD интерфейса. Без активированного SWD программа имеет доступ ко всему адресному пространству без каких-то ограничений ( исключение - PMP регистр, который роняет системку в исключение при доступе к определенному региону памяти).
2) Визуально при работе защиты мы читаем константу ( f3f9bda9 или a9bdf9f3)
3) Защита ставится при записи флеша при активированной галке "code and data protection mode". Записать данные при снятой галке невозможно. По крайней мере мне способ неизвестен.
4) За включение защиты при активированном SWD отвечает бит 7 (CFG_ROM_READ) в системной конфигурационной области 0x0007E000-0x0007EEFF. Но просто взять и переписать это значение нельзя. Там есть поле VALID_SIG , которое нужно правильно посчитать. Иначе не прокатит. Это значение считается через содержание страницы по неизвестному алгоритму. Т.е. для снятия защиты со страницы нужно знать значение самой страницы. Т.е снять защиту сможет только тот, кто ее зашил.

Но там в загрузчике есть баг, который позволяет снять прошивку, которая обновлялась по OTA! Смысл в том, что загрузчик при загрузке мелких программы не трет флеш целиком. Он трет примерно 6.5К. Оставляя стальную информацию в памяти.

Как сливать прошивку:
1) пишем простейшую программу. Цикл чтения от 0 до конца всего адресного пространства. Просто пихаем все в USART. Без библиотек. Минимального размера. По принципу "берем данные - кидаем в регистр.". Без сегмента данных.
2) Пишем в чип. Запускаем. Сливаем весь флеш. Все сливаем. Потом порежете на нужные куски.
3) Но вы скажете что у нас не будет первых 6.5К данных. Печалька? Нет!
4) При обновлении ОТА мы имеем в флеше 2 экземпляра прошивки. Старую и новую. Защита от сбоев заливки прошивки. Ищем 2-й экземпляр этой прошивки. И заменяем отсутствующий фрагмент прошивки из 2-ого куска. И прошивка у вас в руках.

 

[pvvx]

исключение - PMP регистр, который роняет системку в исключение при доступе к определенному региону памяти

Прерывание по исключению у SWD?

Самое неприятное - CPU то-же не видит.

SWD включен в ядро CPU, через его прибамбасы, а не отдельно на шину, где сидит контроллер Flash.

 

[pvvx]

В документации к CH58x нет указания по максимальной частоте CPU, а так же о таймингах работы кода из Flash и из SRAM.
О максимальной частоте для ядра CPU можно только догадываться (в SDK это 80MHz). А процедура mDelayuS(), считающая время в тактах CPU, вынесена в SRAM.
Интересно - тянет ли Flash 12.5 нс выборку при 32-х битах (шине)?
У CH30x описание гласит, что при рабате кода "из Flash" добавляются такты ожидания...

 

[pvvx]

На CH58x не пробовал и не знаю, но есть такое предположение:

Если PMP объявляет доступные для CPU области чтения-записи, то возможно попробовать задать новую область, которая будет выше области реально имеющейся Flash. Возможно, что шинный дешифратор адреса у контроллера Flash ограничен и дублирует её несколько раз в адресное пространство...

 

[il-2]

Привет старожилам. Я начал освоение линейки CH57x/CH58x/CH59x недавно. В архитектуре RISCV я тоже новичек, да и в BLE - тоже. Но вот возникла потребность в BLE. С сторонними модулями поработал - полная Ж. На текущий момент (пока шли заказанные платы с CH573 и CH582) я успел поднатаскаться и в архитектуре RISCV, и в стандарте BLE, и главное - в среде MRS и китайским SDK (про косяки в нем, которые увидел тупым просмотром исходников напишу чуть ниже).
В данный момент мне удалось запустить отладку. Кстати - у меня почти весь день ушло на то, чтобы нормально включить SWD через ISPTool. Все делал вроде правильно - но не включалось хоть тресни. Проблема оказалась тупая как я сам На EasyElectronics есть упоминание - пользователь sed_alex пишет:
... Вуаля у вас устройство включило SWD и теперь его можно шить и отлаживать через SWD... Но при первой же прошивке по USB все вернется назад.
А я после включения SWD следом заливал hex-файл (торопился Целый день упражнялся :-(
Теперь про косяки в SDK, а именно в их PeripheralLib. Это то что я выловил визуально, просматривая код "по диагонали". Проверку пока не делал:
- функция RTC_TRIGFunCfg() - вглядитесь в нее внимательно. Если настройка момента срабатывания должна быть в диапазоне 0...0xA8BFFFFF, то там явная лажа со сравнением - надо сравнивать if (t >= 0xA8C00000) (больше или равно). Конечно вероятность вляпаться мизерная, но о качестве программирования это уже что-то говорит.
- в файле MCU.C в функции CH58X_BLEInit() косяк с настройкой SysTick - SysTick_Config(SysTick_LOAD_RELOAD_Msk); Тут явно была задумка авторов использовать разрядность на полную, да только не учли они что в самой SysTick_Config(uint64_t ticks) из этого ticks вычитается 1 для записи в SysTick->CMP, так что вместо полноразрядного 64-бит счетчика получилось нечто другое.
Там есть еще подобные косяки. Вряд-ли такое скажется на работоспособности, но стиль говорит сам за себя.

Ну и последнее - это просто бомба!!! (предупреждаю, я еще не проверял в железе):
- для доступа к залоченным регистрам используется sys_safe_access_enable(). Как известно, после разлочивания надо выполнить запись в течении 16 тактов.
Так вот - при использовании sys_safe_access_enable() не принимается НИКАКИХ мер к блокировке прерываний!!! Это может приводить к профукиванию записи в регистры и соответственно к сбоям в работе с периферией.
Если библиотека BLE собирается китайцами из исходников с использованием таких-же функций, то нетрудно догадаться к чему это может привести.

Кстати, при компиляции своего проекта я не вижу в map-файле векторов прерывания для BLE. Похоже что библиотека BLE не использует вообще никаких прерываний. Но с этим тоже еще предстоит разобраться.

 

[pecherskih]

Привет старожилам. Я начал освоение линейки CH57x/CH58x/CH59x недавно. В архитектуре RISCV я тоже новичек, да и в BLE - тоже. Но вот возникла потребность в BLE. С сторонними модулями поработал - полная Ж. На текущий момент (пока шли заказанные платы с CH573 и CH582) я успел поднатаскаться и в архитектуре RISCV, и в стандарте BLE, и главное - в среде MRS и китайским SDK (про косяки в нем, которые увидел тупым просмотром исходников напишу чуть ниже).
В данный момент мне удалось запустить отладку. Кстати - у меня почти весь день ушло на то, чтобы нормально включить SWD через ISPTool. Все делал вроде правильно - но не включалось хоть тресни. Проблема оказалась тупая как я сам На EasyElectronics есть упоминание - пользователь sed_alex пишет:
... Вуаля у вас устройство включило SWD и теперь его можно шить и отлаживать через SWD... Но при первой же прошивке по USB все вернется назад.
А я после включения SWD следом заливал hex-файл (торопился Целый день упражнялся :-(
Теперь про косяки в SDK, а именно в их PeripheralLib. Это то что я выловил визуально, просматривая код "по диагонали". Проверку пока не делал:
- функция RTC_TRIGFunCfg() - вглядитесь в нее внимательно. Если настройка момента срабатывания должна быть в диапазоне 0...0xA8BFFFFF, то там явная лажа со сравнением - надо сравнивать if (t >= 0xA8C00000) (больше или равно). Конечно вероятность вляпаться мизерная, но о качестве программирования это уже что-то говорит.
- в файле MCU.C в функции CH58X_BLEInit() косяк с настройкой SysTick - SysTick_Config(SysTick_LOAD_RELOAD_Msk); Тут явно была задумка авторов использовать разрядность на полную, да только не учли они что в самой SysTick_Config(uint64_t ticks) из этого ticks вычитается 1 для записи в SysTick->CMP, так что вместо полноразрядного 64-бит счетчика получилось нечто другое.
Там есть еще подобные косяки. Вряд-ли такое скажется на работоспособности, но стиль говорит сам за себя.

Ну и последнее - это просто бомба!!! (предупреждаю, я еще не проверял в железе):
- для доступа к залоченным регистрам используется sys_safe_access_enable(). Как известно, после разлочивания надо выполнить запись в течении 16 тактов.
Так вот - при использовании sys_safe_access_enable() не принимается НИКАКИХ мер к блокировке прерываний!!! Это может приводить к профукиванию записи в регистры и соответственно к сбоям в работе с периферией.
Если библиотека BLE собирается китайцами из исходников с использованием таких-же функций, то нетрудно догадаться к чему это может привести.

Кстати, при компиляции своего проекта я не вижу в map-файле векторов прерывания для BLE. Похоже что библиотека BLE не использует вообще никаких прерываний. Но с этим тоже еще предстоит разобраться.

А ты что хотел от китайцев? Думаешь нам легко?

 

[pvvx]

А ты что хотел от китайцев? Думаешь нам легко?

Не надо путать китайцев, к примеру WCH и Telink (TLSR82xx).
У Telink сам CPU потупее, но так называемые "китайцы" слепили к нему адекватную периферию и описания с SDK не расходятся, как и тяжелых ляп у них нет.
И это не один пример. Но вам надо было брать самое "г", т.к. "народ" всегда выбирает самое худшее
И из этого и вытекает, что без Debug с такими чипами никак. В других он нафиг не сдался, т.к. как напишешь, так и работает.

 

[pvvx]

На текущий момент (пока шли заказанные платы с CH573 и CH582) я успел поднатаскаться и в архитектуре RISCV, и в стандарте BLE

На СИ разве есть какая разница в RISCV и ARM?
Или решили писать на ASM, в наше то время?

Освоение BLE - это большой ком сразу по башке... Покрутите годик и только тогда разберетесь. А потом уже в SDK от разных производителей, т.к. у них у всех разная интерпретация и вообще парадигма (китайцы).
Хотя давно есть стандарт на все BLE функции с их аргументами...
Использовать WCH нет никакой возможности - у них в либах нет функций для BT5.0 от 2016 года... А на дворе - BT5.4...