BLE SoC PHY6202

[pvvx]

В стандарте BT где-то должно быть описано сколько может быть максимальный уход часов в ppm.
ESP32 тоже страдает уходом часов, но ещё больше. По этому там BT не работает без доп. кварца.

 

[cool2000]

Какая стабильность пересчета RC вышла в новых вариантах SDK?

Как это можно оценить? Пока только смотрю за коэффициентом пересчёта RC Clk в XTAL16. Он стабилен, в моем варианте RC Clk ниже на ~0.5%, питание 3.3В.
В сам алгоритм калибровки пока не лез. Там непаханное поле для оптимизации.
Сейчас на выполнение калибровки уходит порядка 1.5мс. Судя по стабильности коэффициента, можно калибровку делать реже, раз в 10 циклов сна.

 

[pvvx]

Как это можно оценить? Пока только смотрю за коэффициентом пересчёта RC Clk в XTAL16. Он стабилен, в моем варианте RC Clk ниже на ~0.5%, питание 3.3В.

Можно взять уход за сутки для версии работающей по типу THB2, т.е. дающей рекламу со средним периодом...
Хотя это не cовсем корректно, но при стабильности Vcc и температуры сгодится для расчета отклонений в ppm.
Не корректно, т.к. смотрел разницу у разной длительности sleep. При нарушении добавочного коэф., который идет константой на старт выходят разные отклонения.

Судя по стабильности коэффициента, можно калибровку делать реже, раз в 10 циклов сна.

почему-то не потянуло. Батарейка дает нестабильное напряжение. После разной нагрузки напряжение в sleep восстанавливается по разному. Даже при малейшей разнице нагрузки. Там отношения более 1000 токов sleep и работы с TX. Естественно батарейка восстанавливает напряжение в sleep разное время после удара... И коэф. плавает.
При старте connect вообще нагрузка меняется -> наработанный коэф. не годится.
PHY слепили горбатого - дурной RC генератор - очень нестабильный.

 

[pvvx]

И время восстановления напряжения у батарейки зависит от емкости кондера в питании....
У TLSR825x вроде хороший стабилизатор, но его колбасит от температуры. А у PHY от напряжения питания

 

[pvvx]

Если совсем упрощенно прикинуть при уровне стабилизации тока или напряжения для RC гена, то:
При качестве стабилизации источника в 60 дБ -> 1000 раз.
Напряжение питания 3.3..2.0В -> различие в 1.65 раз.
1.65/1000 = 0.00165, в ppm это 1650 ppm (?)

Внутренне сопротивление CR2032 для расчетов можно брать 5..100 Ом (новый .. почти умер).
Замер RC происходит при нагрузке в ~5 mA, если нет TX. Что дает провал напряжения относительно sleep в 0.5В...

 

[pvvx]

А основное время RC работает при нагрузке на батарею в пару мкА. Но расчет хода RC ведется при 5+мА

 

[pvvx]

Так же неизвестно от какого источника питается RC ген. А прошивка переключает напряжение в sleep на пониженное...
В итоге китайская настройка не работала. Но я ничего из выше перечисленного не учитывал, а просто переписал саму процедуру расчета и ранее отказывающиеся работать на 3.3 В чипы заработали. Но не все, т.к. пользовали пишут что некоторые единичные варианты чипов не хотят работать (сказывается именно на начало BLE соединения - не соединяется)

 

[cool2000]

Так же неизвестно от какого источника питается RC ген.

От какого-то внутреннего опорника скорее всего.

пользовали пишут что некоторые единичные варианты чипов не хотят работать (сказывается именно на начало BLE соединения - не соединяется)

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

Бегло пробежался по текстам сравнивая код wakeup_init1() и wakeupProcess1() у вас и в SDK3.1.3. Больших отличий не увидел. Из того, что бросилось в глаза. Вы закомментировали вызов hal_system_clock_change_process(), но это просто заглушка, код будет вызываться, только если адрес записан в jump table

Спойлер: hal_system_clock_change_process()

void hal_system_clock_change_process(void)
{
    typedef void (*my_function)(void );
    my_function pFunc = NULL;
    pFunc = (my_function)(JUMP_FUNCTION(HAL_SYS_CLK_CHG_PROC));

    if (pFunc != NULL)
        pFunc();
}

И ещё у вас намного больше задержки в RC32K clock при просыпании - 50 и 15: patch.c line:5480
В SDK3.1.3 соответственно 15 и 5. Получается порядка 1.5мс дополнительно.

 

[pvvx]

Бегло пробежался по текстам сравнивая код wakeup_init1() и wakeupProcess1() у вас и в SDK3.1.3. Больших отличий не увидел.

Там вроде всё по мелочи, но в разных местах. В инициализация переменных и вообще использовании самих переменных пересчета частоты RC...
В изначальном SDK был бардак и много лишнего.
Всё лишнее тупо вырезал, т.к. был расчет на то, что Вы почините SDK на LR, тогда и допилить.

 

[pvvx]

И ещё у вас намного больше задержки в RC32K clock при просыпании - 50 и 15: patch.c line:5480
В SDK3.1.3 соответственно 15 и 5. Получается порядка 1.5мс дополнительно.

Это всё выкинуто, путем назначения CLK_16M_ONLY = 1
Чистка была только для CLK_16M. Остальное просто откинуто defined CLK_16M_ONLY и явно нерабочее.
Нафига в прошивке ветвления на несколько килобайт в критических местах, если другой CLK не используется?

 

[cool2000]

Чистка была только для CLK_16M. Остальное просто откинуто defined CLK_16M_ONLY и явно нерабочее.
Нафига в прошивке ветвления на несколько килобайт в критических местах, если другой CLK не используется?

С этим трудно не согласиться.
Зачем-то в SDK3.1.3 ещё добавили код динамического изменения частоты MCU.
LR на 16M не проверял. У китайцев этот проект запускается на 48M. Критическое место - ответ на запрос на соединение за 150мкс из-за большой задержки Rx HW.

 

[pvvx]

Дык производительность CPU в данном SoC зависит не от CLK CPU, а от CLK SPI к Flash.
После пробуждения кэш XIP всегда пустая. При 32MHz CLK SPI имеем всего до пары мегабайт выборок байтов кода и данных в секунду...
Всё запихать в ret. RAM не выйдет.
Надо ещё жестче резать код

 

[cool2000]

Дык производительность CPU в данном SoC зависит не от CLK CPU, а от CLK SPI к Flash.

В этом случае, весь код исполняется из RAM и все упирается в производительность. Если переключить Clk на 16М, то соединение перестает устанавливаться. PHY не успевает ответить на запрос.
Получается имеем связку adv_indication -> con_request -> con_response, с интервалами 150мкс. Для первых двух в режиме tx-rx интервал обрабатывается аппаратно.
И далее по приёму con_request нужно ответить за 150 мкс. Из-за большой задержки в аппаратном блоке PHY при тактовой 16 МГц не укладывается в этот интервал.

 

[pvvx]

Из-за большой задержки в аппаратном блоке PHY при тактовой 16 МГц не укладывается в этот интервал.

Это плохо, т.к. при большей частоте увеличивается ток потребления, а время активности не сокращается из-за длительности RF транзакций и необходимых пауз. Но из-за увеличения тока более всего сказывается просадка батарейки на её внутреннем сопротивлении.
В итоге при большем токе имеем раннее ограничение времени работы батареи - у CRxxxx батарей по мере разряда увеличивается внутреннее сопротивление, а напряжение так и остается 3В (+25С) если измерять без нагрузки.
Пики RF TX можно сгладить емкостью в питании, но не общий ток активности... А в LR для сглаживания TX потребуется емкость в 8 раз больше, а оно тоже имеет утечку - чем больше емкость, тем больше утечка...

 

[cool2000]

Согласен, где-то китайцы налвжали при разработке декодера LE Coded. Кстати так и не ответили мне, чем закончились их изыскания.
А вы же измеряли на сколько возрастает потребление процессора при изменении тактовой частоты?

 

[pvvx]

Если потребление при TX будет 8 мА (это примерно +0 дБм), тогда CR2032 возможно гнать до 120 Ом внутреннего сопротивления (падение от 3В в 2В в момент TX, при +25С на батарее).
Т.е. отладку надо делать через резистор в ~150 Ом от источника в 3.3В (?)

 

[cool2000]

Т.е. отладку надо делать через резистор в ~150 Ом от источника в 3.3В (?)

Попробую.
И видимо придётся отключить все выводы, иначе будет подсасывать питание через линии UART.

 

[pvvx]

Тогда и скажется кривизна RC...