BLE SoC PHY6202

[cool2000]

Дайте дополнительную команду сброса датчику в init_sensor()

Не помогло.

 

[pvvx]

У меня всего один THB2. Остальные в пути по почте. Через пару дней, судя по трекам, похоже будут...

 

[cool2000]

Возможно залил флюсом, когда провода припаивал.

 

[pvvx]

Проблему с таймером нашел - кому-то нужно помнить стек во время сна (или не включают питание всей памяти при пробуждении). Буду искать как обойти.

 

[pvvx]

wakeupProcess0/wakeupProcess1 используют __set_MSP(pGlobal_config[INITIAL_STACK_PTR]);
Наверно во время этих команд питание на всю RAM ещё не включено?

 

[pvvx]

Пока ограничил память Retention RAM. Режим соединение стал стабильным.
До этого оптимизировал код - выкинулось около 1 килобайта часто исполняемого ненужного кода.
Не работает переключение соединения на Coded PHY - нет реализации в данной версии SDK.
При близком расстоянии (хорошем уровне сигнала) текущая программа соединяется и переключается c 1M на 2M PHY.
Т.е. в принципе с SDK для GCC всё - объем итогового кода меньше чем в Keil.

 

[cool2000]

Я попытался проследить как используется и переключается стек.

• ResetHandler sp <= 0x1FFF1830
  • rom_boot() sp <= 0x1FFF1830
  • wakeupProcess0() sp <= [0x1fff0814] + 0x80 - какой-то мелкий стек для нужд ll_*?
  • wakeupProcess1() sp <= pGlobal_config[INITIAL_STACK_PTR] в версии keil, в версии gcc адрес конца ram

В rom прослеживаются чтения из адреса 0x1fff0814 и работа со смещениями к нему. Но не видно, когда туда что-то записывается.
При этом, судя по всему изменение RAM retention в SDK не предусмотрено.
в wakeupProcess0() функция hal_pwrmgr_RAM_retention_clr() или её аналог не вызывается, а в wakeupProcess1() в какой-то момент была закомментирована.

    //=======fix sram_rent issue 20180323
    //hal_pwrmgr_RAM_retention_clr();
    //subWriteReg(0x4000f01c,21,17,0);

Нет этого вызова и нигде в примерах, при этом во всех примерах hal_pwrmgr_RAM_retention_set() исправно вызывается перед переходом в сон. Скорее всего, если раскомментировать hal_pwrmgr_RAM_retention_clr() после переключения стека, то в wakeupProcess1(), то это должно помочь.

 

[pvvx]

Включение питания на куски RAM требует времени - пока там стабилизируется - наверно по этому и вырезали.
Это уже частная задача для того кому нужно всю RAM во время активности. И думаю она решается.
Есть другие задачи - ещё не известно что будет при стирании Flash на ходу соединения. Т.е. какие функции должны быть в RAM, а какие в XIP, чтобы не нарушать тайминг соединения...

 

[pvvx]

А пока выходит, что получившийся SDK будет первым полностью имеющим открытые исходники BLE для мелких SoC (без блобов либ).

 

[cool2000]

Включение питания на куски RAM требует времени - пока там стабилизируется

Несколько мкс? Можно после вызова hal_pwrmgr_RAM_retention_clr() тупо поставить memset 0xFF (0x00) на верхний блок включенной памяти для ускорения.

Не работает переключение соединения на Coded PHY

Вроде в текстах мелькает

        case GAP_LINK_ESTABLISHED_EVENT:
            gapRole_state = GAPROLE_CONNECTED;
            g_rfPhyPktFmt = PKT_FMT_BLR125K;
            notify = TRUE;
            break;

И есть проверки g_rfPhyPktFmt == PKT_FMT_BLR125K в других местах.
А если нагло присвоить g_rfPhyPktFmt = PKT_FMT_BLR125K

 

[cool2000]

ещё не известно что будет при стирании Flash на ходу соединения.

Возможно имеет смысл использовать промежуточный загрузчик, который будет проверять, что в верхней flash записан правильный образ обновления, переписывать его на своё место, после чего стирать обновление. Тогда можно при передаче OTA писать flash мелкими блоками.

 

[cool2000]

PS TH05 у меня есть. Как раз собираюсь снять прошивку и вызвонить куда подключен сенсор.

 

[pvvx]

Смысла при соединении использовать Long Range в практике нет.
Зачем вам соединение c устройством на расстоянии в 1 км? Тогда любой получит доступ к нему. И тут без всяких пин-кодов не обойтись.
Проще ограничить дальность для соединения по RSSI и использовать 2M PHY.
Соединение обычно нужно для начальных настроек устройства и OTA. Остальное пусть работает по BLE рекламе, тем более в BT5.4 стандарте уже есть PAwR (реклама с подтверждением и ответом = упрощенный Zigbee или MESH).

 

[pvvx]

PS TH05 у меня есть. Как раз собираюсь снять прошивку и вызвонить куда подключен сенсор.

По нему уже есть и логи шин... И уже есть с убитым сенсором - накрылся от проводка и статики (эти датчики постоянно летят - это из производственной практики). Но есть ещё несколько энтих TH-05.

 

[pvvx]

С TH-05 по току sleep всё плохо.
Драйвер LCD + SoC(3 мкА) + датчик - уже получаем 10 мкА. (Xiaomi LYWSD03MMC - 6 мкА)
А CR2032 это в среднем 100 мАч, т.к. не любит импульсную нагрузку - просаживает напряжение при импульсе передачи, а кондеров в питании нет - внутреннее сопротивление полуразряженного CR2032 уже к 100 Ом.
В итоге получим всего в среднем 100/0.02 = 5000 часов работы, т.е. пол года.

 

[pvvx]

И есть проверки g_rfPhyPktFmt == PKT_FMT_BLR125K в других местах.

Но nRFConnect не переключает на Coded PHY во время соединения. На 1M и 2M переключает.
Может надо что-то задать в инициализации.
Обычно поддерживаемые PHY и желаемые, т.е. предлагаемые по приоритету при соединении задаются в инициализации масок всяких LL и т.д.
Но начало соединения, по стандарту Bluetooth, "снюхивание" всегда на 1M или Coded S8 PHY, как и реклама на основных каналах.
Китайщины с рекламой на 2M PHY или других мне не надо. Это несовместимо ни с чем.

 

[cool2000]

В малопотребляющий (при правильной прошивке ) THB1 поставили 2 батарейки ААА, а в жрущий TH05 дохлую CR2032.

Посмотрел ещё раз: wakeupProcess0() стек устанавливается аналогично wakeupProcess1()

• wakeupProcess0() sp <= pGlobal_config[INITIAL_STACK_PTR]

функция hal_pwrmgr_RAM_retention_clr() или её аналог не вызывается.

А рекламу можно слать в режиме Coded S8 PHY?

 

[cool2000]

.

 

[pvvx]

Тем более Web Bluetooth API не может включить сканирование на Coded S8 PHY из-за игнора BLE в Linux с 2014 года.
Android, MAC и Windows уже имеют переключения и поддержку стандартов BT5+, но в низкоуровневой реализации. И то благодаря Google, который перепатчил своё ядро Linux под Android. От Linux там осталось только название...

 

[pvvx]

А рекламу можно слать в режиме Coded S8 PHY?

По стандарту BT на основных каналах только в Coded S8 PHY и 1M РНY. Есть понятие первичный и вторичный РНY. Coded S8 PHY применяется только в "расширенной рекламе" (BT5.0 и необязательные для реализации дополнения BT4.2) в заголовке на основных каналах. Вторичный PHY может быть любым - на нем транслируются сами данные рекламы на дополнительных каналах в "расширенной рекламе", а указание где и какой PHY в заголовке на основных каналах.