WIFI bootloop

[ianchi]

Hi, I have a CBU module from a AT/Tongou TO_Q_SY1_JWT that gets into bootloop when adding the WIFI component.

I have flashed many other identical devices with no problem, but this one doesn't start.

I tried with a totally bare config and added a few components, to find the offending one is WIFI

Any suggestion to debug it?

WORKING YAML

substitutions:
  node_id: bare-bk
  verbose_name: "Bare"

esphome:
  #name_add_mac_suffix: true
  name: ${node_id}
  comment: ${verbose_name}

preferences:
  flash_write_interval: 1s

bk72xx:
  board: cbu

  framework:
    loglevel: verbose
    debug:
      - wifi
      - ota

logger:
  level: VERY_VERBOSE
  hardware_uart: UART1

status_led:
  pin:
    number: P15
    inverted: true

switch:
  - platform: gpio
    name: ${verbose_name}
    pin: P26
    id: relay
    restore_mode: RESTORE_DEFAULT_ON

binary_sensor:
  - platform: gpio
    id: hard_button
    pin:
      number: P17
      inverted: true
    on_click:
      - switch.toggle: relay
      - output.turn_on: led_red
      - delay: 10s
      - output.turn_off: led_red

output:
  - platform: gpio
    id: led_red
    pin:
      number: P9
      inverted: true

Offending config

Above config boots and works well. It fails if I add:

wifi:
  ssid: MY-SSID
  password: "MyWifiPswd"

Serial Log Output

I [      0.022] logger
[C][status_led:014]: Setting up Status LED...
[I][app:029]: Running through setup()...
[V][app:030]: Sorting components by setup priority...
[VV][scheduler:063]: set_interval(name='', interval=1000, offset=466)
[C][switch.gpio:011]: Setting up GPIO Switch 'Bare'...
[VV][lt.preferences:064]: fdb_kv_get_blob: key: 1274655749, len: 1
[D][switch:016]: 'Bare' Turning OFF.
[VV][lt.preferences:041]: s_pending_save: key: 1274655749, len: 1
[D][switch:055]: 'Bare': Sending state OFF
[D][switch:016]: 'Bare' Turning OFF.
[D][binary_sensor:034]: 'hard_button': Sending initial state OFF
[C][wifi:048]: Setting up WiFi...
[C][wifi:061]: Starting WiFi...
[C][wifi:062]:   Local MAC: 1C:90:FF:15:07:49
[VV][lt.preferences:061]: NVS length does not match (0!=98)
[V][wifi_lt:035]: Enabling STA.
D [      0.112] WIFI: Mode changing NULL -> STA
D [      0.116] WIFI: Initializing func&app

It repeats the loop every 10s or so.

Another weird thing with this chip is that I get a bunch of CRC missmatch while checking chip type! in ltchiptool while flashing. After a couple of retries it flash though.

I also tried two different power sources to rule out power issues, but it gets in bootloop with both.

By the way, @kuba2k2 congrats on the great work you've done with this project!!

[kuba2k2]

Make sure your power supply is good enough. This issue is usually caused by a weak power supply, bad wires etc.

[dwmw2]

Don't leave P26 on either; that might not be helping with the power stability. See https://devices.esphome.io/devices/Tongou-TO-Q-SY1-JWT for a sample config which pulses P24 to close the relay and P26 to open it. (Which will be even simpler once https://github.com/esphome/esphome/pull/7421 is merged).

Does this problem still happen if you use LWIP 2.1.3 which was in the LibreTiny 1.6.0 and earlier releases?

[numaiiiir]

Hi, I have a CBU module from a AT/Tongou TO_Q_SY1_JWT that gets into bootloop when adding the WIFI component.

I have flashed many other identical devices with no problem, but this one doesn't start.

I tried with a totally bare config and added a few components, to find the offending one is WIFI

Any suggestion to debug it?

WORKING YAML

substitutions:
  node_id: bare-bk
  verbose_name: "Bare"

esphome:
  #name_add_mac_suffix: true
  name: ${node_id}
  comment: ${verbose_name}

preferences:
  flash_write_interval: 1s

bk72xx:
  board: cbu

  framework:
    loglevel: verbose
    debug:
      - wifi
      - ota

logger:
  level: VERY_VERBOSE
  hardware_uart: UART1

status_led:
  pin:
    number: P15
    inverted: true

switch:
  - platform: gpio
    name: ${verbose_name}
    pin: P26
    id: relay
    restore_mode: RESTORE_DEFAULT_ON

binary_sensor:
  - platform: gpio
    id: hard_button
    pin:
      number: P17
      inverted: true
    on_click:
      - switch.toggle: relay
      - output.turn_on: led_red
      - delay: 10s
      - output.turn_off: led_red

output:
  - platform: gpio
    id: led_red
    pin:
      number: P9
      inverted: true

Offending config

Above config boots and works well. It fails if I add:

wifi:
  ssid: MY-SSID
  password: "MyWifiPswd"

Serial Log Output

I [      0.022] logger
[C][status_led:014]: Setting up Status LED...
[I][app:029]: Running through setup()...
[V][app:030]: Sorting components by setup priority...
[VV][scheduler:063]: set_interval(name='', interval=1000, offset=466)
[C][switch.gpio:011]: Setting up GPIO Switch 'Bare'...
[VV][lt.preferences:064]: fdb_kv_get_blob: key: 1274655749, len: 1
[D][switch:016]: 'Bare' Turning OFF.
[VV][lt.preferences:041]: s_pending_save: key: 1274655749, len: 1
[D][switch:055]: 'Bare': Sending state OFF
[D][switch:016]: 'Bare' Turning OFF.
[D][binary_sensor:034]: 'hard_button': Sending initial state OFF
[C][wifi:048]: [192.168.1.128]Setting up WiFi...
[C][wifi:061]: Starting WiFi...
[C][wifi:062]:   Local MAC: 1C:90:FF:15:07:49
[VV][lt.preferences:061]: NVS length does not match (0!=98)
[V][wifi_lt:035]: Enabling STA.
D [      0.112] WIFI: Mode changing NULL -> STA
D [      0.116] WIFI: Initializing func&app

It repeats the loop every 10s or so.

Another weird thing with this chip is that I get a bunch of CRC missmatch while checking chip type! in ltchiptool while flashing. After a couple of retries it flash though.

I also tried two different power sources to rule out power issues, but it gets in bootloop with both.

By the way, @kuba2k2 congrats on the great work you've done with this project!!

[ianchi]

hi @dwmw2 great work on the calibration feature!! I suspected my devices where a bit off with the readings.

Regarding the bootloop, I already tried with two power sources, both worked well with 5 other identical devices. I'm also disconected the board from the rest of the circuit, so the relay is actually not present and so doesn't draw any power. I've been using version 1.6

Today I updated to esphome 2024.09 which includes your PRs and v1.7 Also set P24 & P26 to ALWAYS_OFF

I get exactly the same bootloop when initializing WIFI and still a lot of random CRC missmatchs when reading the flash.

This was the first device I used to experimet a couple of months back, and I did some soldering to it. I fear something went wrong in the process.

[ianchi]

@dwmw2 a question regarding calibration data in the original firmware. I don't have the devices connected to Tuya any more, but I do have flash dumps for some of them.

I had extracted them with ltchiptool at the time, and now I try to read them at the offset you said in the docs, but I've got nothing there.

Any ideas how to recover the info?

This is from the dump:

2097152 Jul 11 19:05 ltchiptool_bk72xx_2024-07-11_18-58-27.bin

bk7231tools  dissect_dump ltchiptool_bk72xx_2024-07-11_18-58-27.bin
RBL containers:
        0x10f9a: bootloader - [encoding_algorithm=NONE, size=0xea20]
        0x129f0a: app - [encoding_algorithm=NONE, size=0xe9d00]
Storage partition:
        0x1ee000: 32 KiB - 7 keys
        - 'gw_bi'
        - 'user_param_key'
        - 'gw_di'
        - 'gw_wsm'
        - 'wf_start_md'
        - 'gw_ai'
        - 'save_off_stat'

And at the specified offset of the file I get

Format-Hex .\ltchiptool_bk72xx_2024-07-11_18-58-27.bin -Offset 0x001d5000 -count 32

   Label: ltchiptool_bk72xx_2024-07-11_18-58-27.bin

          Offset Bytes                                           Ascii
                 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
          ------ ----------------------------------------------- -----
00000000001D5000 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
00000000001D5010 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ

What it the “key value store” partition you mention in the docs? According to bk7231tools above the "storage partition" is at offset 0x1ee000 which is after your address.

I also extracted the storage partition keys to json, and none seem to have this caldata info.

[dwmw2]

We should continue the calibration part in https://github.com/libretiny-eu/ltchiptool/issues/38