BLE SoC PHY6202

[pvvx]

Примерный приоритет, того что необходимо знать при разработке на PHY62x2:

• Как работает загрузчик в ROM – как обрабатывает таблицу загрузки из Flash по адресу 0x2000.
• Какие области RAM пользуют процедуры в ROM.

Второстепенная задача, т.к. для Cortrex M0 есть куча дизасм и любая процедура в блобах замещается опциями линковщику или есть такое – запатчить нафиг в obj:

• Какие области RAM пользуют процедуры блоб-либы RF, если она используется.

На этом всё. Остальное безразлично.

 

[pvvx]

Переписать можно всё что угодно, это не вопрос. Вопрос нужно ли?

Это смотря что быстрее - мне быстрее написать своё, чем ковыряться в наслоениях г...
Мы уже тут написали больше и затратили время больше, чем накатать код для решения всех проблем в PHY.

 

[pvvx]

А пока нет информации по указанным пунктам и лень тратить на это время.
Но есть любители подстраиваться и изучать чужое...

 

[pvvx]

Процедуры приема-передачи есть, остальное для связи BLE есть. Функция записи Flash есть. = полный достаток для написания программы OTA.
Но нет описания как себя ведет ROM, для создания качественного переключения на загруженный OTA.

 

[pvvx]

Из известной информации уже можно сделать OTA. Но переписывать на ходу область 0x2000 небезопасно. Вдрух в этот момент батарейка отвалится? - Будет кирпич.

Китайцы в итоге нагородили специальный загрузчик… Но вдруг разработчик ROM не был таким дураком и предусмотрел поиск - переключение блока разметки загрузки в Flash, как это сделали другие нормальные разработчики? Тогда можно записать блок новой разметки по другому адресу в Flash и только после этого стереть прошлую запись.

 

[cool2000]

Но переписывать на ходу область 0x2000 небезопасно.

То же самое касается и области 0x5000. Поэтому предлагается в области 0x5000 разместить промежуточный загрузчик+OTA, который затем читает разметку в области 0x3000 и загружает основное приложение с области 0x11000. Этот загрузчик + область 0x2000 записывается однократно через UART, основное приложение + область 0x3000 через OTA. Вся функция ROM в этом случае сводится к запуску промежуточного загрузчика и не нужно заморачиваться с переключением flash.

 

[pvvx]

Вся функция ROM в этом случае сводится к запуску промежуточного загрузчика и не нужно заморачиваться с переключением flash.

Это детский метод, с лишними затратами объема Flash, вместо того, чтобы записывать историю замеров.
Если вы запишите кривую программу, то всё равно всё зависнет, т.к. разметка после OTA кривого кода для вашего лоадера будет правильная и он запустит эту кривую программу.
Т.е. отдельный загрузчик не имеет смысла. Совсем, кроме желания пожрать больше батареек и уменьшить объем записи истории.

 

[pvvx]

Gidra на ROM PHY6222 сказала, что используются такие адреса Flash (и функции которые их используют):

0x11001800.. HCI_ExtTaskRegister()
0x11001818 rom_board_init()
0x11002000.. boot_m0()
0x11002100.. boot_m0()

HCI_ExtTaskRegister() из данных в Flash инициализирует spif_config().
boot_m0() как раз разбирается с таблицей загрузки.

Вроде в flash больше никто из ROM не лезет.
В RAM есть обращения до 0x1fff1d30 + смещение. Разгадывать сколько в плюс не стал - и так понятно что 8 килобайт...

 

[cool2000]

0x11001800.. HCI_ExtTaskRegister()0x11001818 rom_board_init()

Обращения из ROM PHY6222 во flash:

• 0x11001800 - параметры int spif_config(sysclk_t ref_clk, uint8_t div, uint32_t rd_instr, uint8_t mode_bit, uint8_t QE);
• 0x11002000 - число блоков, стартовый адрес
• 0x11002100 - разметка для загрузки приложения из flash
• 0x11002800 - параметры secure boot

 

[pvvx]

Обращения из ROM PHY6222 во flash:

• 0x11001800 - параметры int spif_config(sysclk_t ref_clk, uint8_t div, uint32_t rd_instr, uint8_t mode_bit, uint8_t QE);
• 0x11002000 - число блоков, стартовый адрес
• 0x11002100 - разметка для загрузки приложения из flash
• 0x11002800 - параметры secure boot

Зачем дублируете? Решили написать документацию?
Gidra говорит какие значения из 0x11002000 используются для шифрации и по какому параметру там производится проверка сегмента на CRC...

 

[cool2000]

по какому параметру там производится проверка сегмента на CRC...

Почему не используете CRC в разметке (0x2000)?

Как я понимаю, в текущей версии прошивки включен только сервис OTA application, обеспечивающий проверку ключей и перезагрузку в режим OTA, т.е. Bootloader OTA всё равно нужен?

 

[pvvx]

Почему не используете CRC в разметке (0x2000)?

Зачем?

Как я понимаю, в текущей версии прошивки включен только сервис OTA application, обеспечивающий проверку ключей и перезагрузку в режим OTA, т.е. Bootloader OTA всё равно нужен?

Да.
По этому проще вписать свой OTA в каждую прошивку. Он займет меньше сектора flash, совместно в двух прошивках. А Bootloader OTA требует много объема Flash.
Нужно обслужить всего один UUID с RD/WR.

 

[pvvx]

@cool2000 - Вы "разгадали" как переключать сегменты Flash для отображения и исполнения кода в разных областях адресов (XIP)?
Кто обеспечивает мапинг сегментов при загрузке?
Без этого OTA не выйдет - вам потребуется писать разные программы для разных OTA областей Flash

 

[pvvx]

Почему не используете CRC в разметке (0x2000)?

При неправильном обновлении или плохой записи в Flash всё равно выйдет "кирпич", способный только на программирование через COM порт.
CRC - это лишняя трата батарейки при старте устройства. Больше этот CRC ничего не дает. Никакой функциональности не расширяет, а только запутает пользователей. При частичной "битой" программе в Flash OTA может и заработать, а c проверкой CRC - нет и при сбое при старте/рестарте посадит батарейку нафиг - вывалится в загрузчик по COM порту и так и будет ждать, пока батарейка не скончается. А это вероятность в десятки процентов при питании от солнечной панели.
А при загрузке с плавающим питанием, первая функция enable_wdt() на 90% исполнится...

 

[pvvx]

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

 

[pvvx]

Что-то кривое в SDK 3.1.3. Sleep на 2 мкА больше, чем в SDK 3.1.1(вариант 2).
Так же во всех оф. SDK от PHY есть кучка ошибок... в подарок Такое впечатление, что они сырые и никто их не проверял, а кинули на затравку...
Надоело исправлять.
Да, и совместимости тоже нет со старыми версиями на дцать процентов. Т.е. при обновлении SDK, всё необходимо всегда переписывать, кроме своих функций.

 

[pvvx]

Sleep на 2 мкА больше и то, если пропатчить имеющиеся открытые куски кода. Иначе, по задумке PHY писателей SDK, потребление в sleep будет на десятки мкА больше, как и пишут в документации
Так и потребляет оригинальный код от Tuya.

 

[cool2000]

Что-то кривое в SDK 3.1.3. Sleep на 2 мкА больше, чем в SDK 3.1.1

Возможно это?

### **Version**: PHY62XX_SDK_3.1.3
### **Change List**
### **[components]**

driver:
pwrmgr: 1.Bugfixed AON register abnormal,use rom interface
2.LDO low current bit set zero when CFG_SRAM_RETENTION_LOW_CURRENT_LDO_ENABLE is not define
3.Reset all common peripheral interrupt priority to IRQ_PRIO_HAL after wakeup

Итак, в заводской прошивке сервис OTA Application отсутствует, соответственно приложение phyOTA не может запустить режим обновления. Одна надежда на OTA Bootloader, если получится активировать в нём режим обновления.

 

[pvvx]

Возможно это?

Это я сразу исправил. Иначе бы sleep был как у Tuya.

Итак, в заводской прошивке сервис OTA Application отсутствует, соответственно приложение phyOTA не может запустить режим обновления. Одна надежда на OTA Bootloader, если получится активировать в нём режим обновления.

Там вроде нет boot OTA. Там example\OTA\slboot

Примеры OTA в SDK есть. Зачем мучать TestTHB2.hex или оригинал для разгадывания PhyOTA?

Пакет intelhex
python3 Scripts\hexinfo.py slboot.hex

- file: 'slboot.hex'
  entry: 0x1FFF18F9
  data:
  - { first: 0x1FFF0000, last: 0x1FFF040B, length: 0x0000040C }
  - { first: 0x1FFF1838, last: 0x1FFF4E2F, length: 0x000035F8 }
  - { first: 0x1FFFB300, last: 0x1FFFB383, length: 0x00000084 }
  - { first: 0x1FFFF400, last: 0x1FFFF6FB, length: 0x000002FC }

 

[pvvx]

Возможно это?

Проблема глубже. Думаю в блобах. Всё остальное сверил со старым.
Какой-то CLK или ещё чего не выключается... Копать глубже пока некогда. Лучше разобраться с вариантом SDK имеющим все исходники, без всяких либ и собрать его на gcc.