• Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

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

Member
Но переписывать на ходу область 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

Member
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

Member
по какому параметру там производится проверка сегмента на 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

Member
Что-то кривое в 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.
 
Сверху Снизу