Tuya Zigbee Roгter и DIY Smart Switch за 70 руб.

[Slacky]

Мои прошивки при старте проверяют адрес запуска, и если они не там, то перемещаются куда надо, и делают требуемые очистки Flash и т.д.
Типовых запусков OTA только у Telink много. 0x0, 0x8000, 0x20000, 0x40000. Далее идут ещё варианты у Tuya....
Тут без авто-определения запуска не обойтись...

Я поглядел. Пока эта магия мне не достуна )

 

[pvvx]

Там только одна сложность - первая вызываемая процедура (она-же и должна переместить программу во FLash) не должна быть в Flash. Только в RAM, т.к. адресация Flash будет нарушена при несовпадении с адресом OTA.

 

[Slacky]

Там только одна сложность - первая вызываемая процедура (она-же и должна переместить программу во FLash) не должна быть в Flash. Только в RAM, т.к. адресация Flash будет нарушена при несовпадении с адресом OTA.

Я кажется понял ) Проверяю ...

 

[Slacky]

Не, не получилось. Прошивка заливается по ОТА. Перемещается бутлоадером на 0x8000. И все. Дальше висим. На 0x0000 она себя копировать не хочет.

 

[Slacky]

А еще мне не понятно, зачем tuya_zigbee_ota вызывается два раза. Первый раз в самом начале и потом еще раз из drv_platform_init

 

[pvvx]

А еще мне не понятно, зачем tuya_zigbee_ota вызывается два раза. Первый раз в самом начале и потом еще раз из drv_platform_init

Второй раз - это случайно осталось, от старых версий (ранее первые функции были назначены в RAM, а потом места в RAM стало мало)
Хорошо что нашли - удалю второй вызов.

 

[pvvx]

Не, не получилось. Прошивка заливается по ОТА. Перемещается бутлоадером на 0x8000. И все. Дальше висим. На 0x0000 она себя копировать не хочет.

Все вызываемые процедуры должны быть в RAM, так как адресация в Flash при несоответствии адреса старта нарушена.

 

[pvvx]

Все вызываемые процедуры должны быть в RAM, так как адресация в Flash при несоответствии адреса старта нарушена при смещении 0x8000. При смещении на 0, 0x20000, 0x40000 адреса в Flash перестраивает boot чипа.

 

[pvvx]

1. Все вызываемые процедуры должны быть в RAM, так как адресация в Flash при несоответствии адреса старта нарушена при смещении 0x8000.

2. При смещении на 0, 0x20000, 0x40000 адреса для кэша Flash перестраивает boot чипа аппаратно!

В итоге и выходит 2 проверки.
Первая при старте. И она должна учитывать, последующие старты из deep-sleep и т.д....
По этому tuya_zigbee_ota() отрабатывает только при первом старте с Tuya boot_loder.

_attribute_ram_code_
int main(void) {
    // Проверка на старт из Tuya boot_loder по 0x8000 (старт с 0x20000 не проверяется)
    if(*(u32 *)(ZIGBEE_BOOT_OTA_FADDR + 8) == ID_BOOTABLE
    || flag_addr_ok != 0x33CC55AA) {
        tuya_zigbee_ota();
    }
    return flash_main();
}

А второй запуск tuya_zigbee_ota() уже для проверки, что стартовали с 0x20000 = кто-то загрузил Zigbee прошивку по BLE OTA из стороннего ПО (например из ATC флешера).
(TelinkMiFalsher грузит *.zigbee файлы только в 0x40000).

 

[pvvx]

Все процедуры (4шт) вызываемые из tuya_zigbee_ota() должны быть в RAM.
В BLE версии они и так в RAM в SDK.
В новых версиях Zigbee SDK - нет.
Надо дописать атрибут к flash_read_page(), flash_write_page(), flash_write_status(), flash_erase_sector().
И вообще flash.c у меня заменяется в SDK (при сборке лежит в папке "path"), т.к. имеющийся при каждом вызове записи работает с ADC - проверяет напряжение батареи.
На это уходит куча энергии и времени активной работы SoC.
При этом в Zigbee SDK от Telink нельзя использовать ADC в своих целях - проверка при записи и т.д. считает, что ADC уже включен и настроен на замер питания (при каждом старте).
Зачем мне постоянное лишнее потребление +0.4 мА и невозможность использования в SDK ADC? Приходится заменять некоторые процедуры в SDK на свои и делать проверку напряжения батареи когда это требуется, а не когда захотел писатель SDK из Telink - ему же пофиг на ваши батарейки...

 

[pvvx]

И вечно включенное питание на ADC сказывается даже для автономного роутера - вечное дополнение +0.4 мА к 3..5 мА общего потребления при работе CPU (при RF приеме 6+0.4 мА) и доп. задержки ~300..600 мкс при любой записи Flash.
Включенный у вас UART для "отладки" тоже дает доп. потребление, как и любая часть чипа, куда включен CLK, даже на неиспользуемые части. Писателю SDK так было проще

 

[pvvx]

И код работы с Flash в SDK раздут до безобразия на все варианты SPI-Flash. Он учитывает чипы TLSR825x и с внешним отдельным чипом SPI-Flash, а в чипах с внутренним кристаллом SPI-Flash используются только два типа Flash и все коды команд у них одинаковы (малое различие только в обращении к регистру статуса Flash для включения-выключения защиты записи региона boot_loader, которого я не использую).
А вариантов с внешней SPI-Flash за 5 лет не наблюдалось. И эти дополнения видов Flash в SDK появились после слияния кода SDK с новой серией чипов от Telink, которых так-же не наблюдается.

 

[pvvx]

@Slacky - И не забывайте, что предоставленный открытый SDK является только примером для демонстрации и идет с закрытыми библиотеками, и без полной документации и поддержки со стороны Telink.
Т.е. предназначается для пробы демонстраций на их демо-платах и не более.

А для нормального программировании любого приложения берут SDK с полными исходниками + документацию, подписав NDA, и меняют что требуется.

 

[Slacky]

Надо дописать атрибут к flash_read_page(), flash_write_page(), flash_write_status(), flash_erase_sector().

Да, я это уже вчера нонял, заменил и все переместилось. Но сейчас вылезла другая проблема - по какой-то причине теперь этот модуль перестает нормально работать в сети. MCU работает, на кнопки реагирует и проч. А вот RF часть, как будто засыпает. Разбираюсь.

 

[Slacky]

@Slacky - И не забывайте, что предоставленный открытый SDK является только примером для демонстрации и идет с закрытыми библиотеками, и без полной документации и поддержки со стороны Telink.
Т.е. предназначается для пробы демонстраций на их демо-платах и не более.

А для нормального программировании любого приложения берут SDK с полными исходниками + документацию, подписав NDA, и меняют что требуется.

Ну это для частного лица скорей всего не реально. Да наверно и не нужно ...

 

[pvvx]

@Slacky - Доработал немного:

Выкинул хлам вокруг BL0942, типа всякие файлы "app_uart.c" и т.д.
Заменили на простейшие команды, типа :

// Step 1 sec
int32_t app_monitoringCb(void *arg) {
    REG_ADDR16(0x90) = 0xAA58; // Send cmd: "Read full packet"
    return 0;
}
// Task
void monitoring_handler(void) {
    int32_t  power;
    app_monitoring_t *pkt = (app_monitoring_t*)urxb.data;
    if(reg_dma_rx_rdy0 & FLD_DMA_IRQ_UART_RX) { // new data ?
        reg_uart_status0 |= FLD_UART_CLEAR_RX_FLAG | FLD_UART_RX_ERR_FLAG;
        if(urxb.dma_len == PKT_SIZE
          && pkt->head == HEAD
          && checksum((uint8_t *)pkt, PKT_SIZE) == pkt->crc) {
....

Всё само аппаратно заливается в буфер для парсинга без участия CPU...
Не понимаю - зачем CPU выполнять тысячи лишних команд, когда у него есть правильные встроенные в кристалл контроллеры...

Осталось проверить, как будет происходить автоматическое переключение в ZHA разрядности показаний мощности (Power) ...
Пока три диапазона авто-переключения разрядности показометра: 0..327.67W, 32.767..327.67W, 327.67..3276.7W
Остальное пока работает без всяких "причуд" (quirks) - прекрасно понимает всякие ZCL_ATTRID_AC_CURRENT_MULTIPLIER, ..., ZCL_ATTRID_AC_POWER_DIVISOR,....

 

[pvvx]

Плюс сохранений счетчика энергии теперь 26112 штук - 496.8 лет до выработки 10 тысяч циклов записи Flash при сохранении каждую минуту...

 

[pvvx]

Вылепил и эту https://pvvx.github.io/TS000F_TZ3000_xkap8wtb/

Сравнение с типичной Zigbee "Умной розеткой":

Синяя - своя прошивка, желтая - типичная Tuya...
Реакция быстрее - график везде опережает другие типы, особенно WiFi.
Всё успешно влезает в 512K Flash. Zigbee OTA файлы у обоих по 192 кбайта.
Будет время выкину всё github...

 

[pvvx]

Предварительный бардак с FW скинут в https://github.com/pvvx/TlsrSmartSwitch