Issues using libretuya on BK7231N

[rickyelopez]

Following up on my last post here. Good point about uploading @kuba2k2, I should have mentioned that in my last comment. I can neither flash from pio nor using the manual method.

Both ltchiptool uf2 upload firmware.uf2 uart /dev/ttyACM0 and python -m esphome upload <path to yaml> give the same error:

|-- esphome 2022.10.0-dev @ 2022-10-16 00:33:43 -> generic-bk7231n-qfn32-tuya
|-- Using UART
|   |-- Trying to link on /dev/ttyACM0 @ 460800
|   |-- Writing 919054 bytes to 0x011000
ERROR: RuntimeError: Writing Status Register failed: wrote 0x0000, got 0x0001
 - File "/home/ricclopez/.local/lib/python3.10/site-packages/bk7231tools/serial/cmd_flash.py", line 163, in flash_write_sr

I've only been able to successfully (at least, on paper) flash with command:
python ~/repos/hid_download_py/uartprogram -w firmware.bin -u -s 0x00 -d /dev/ttyACM0
using hid_download_py

Do you think the flashing process is what's preventing it from working? When I use the latter command to restore the stock firmware (which I also backed up with this tool), it does go back to working properly.

[kuba2k2]

Hm, right, apparently your BK7231N is a bit different (they can have different internals) and it's incompatible with ltchiptool. I'll have to fix it.

About hid_download_py, there are two problems:

• as said in the docs, the file meant for uploading is bk7231t_app_0x011000.rbl, not firmware.bin
• the offset should be 0x11000, not 0x0, in which case you're overwriting the bootloader.
  After you correct these errors, you should be able to upload the firmware.

I always say it and I'll say it again (so that more people see it):

• do not use hid_download_py, ever - unless you really have to. bk7231tools has a good firmware reading/writing capabilities (ltchiptool and esphome uploaders are based on this).
• also, always check if the target addresses are meant for what you're trying to flash. 0x0 is the bootloader, 0x11000 is the app
• unless you break the bootloader, flashing to 0x0 is never required. Using the so-called QIO binaries is pointless, and only increases flash wear-out in the bootloader region. "UA" binaries are meant to be flashed to 0x11000, and only that is necessary to update the firmware.

In your case, hid download or BkWriter are the only options (for the time being), because apparently bktools has a bug. Try to run bktools manually in writing mode, and report here what it outputs.

[rickyelopez]

Amazing, worked immediately. Thank you! I've read a lot of documentation over the last couple of days while working on this, I guess I got myself confused. Thanks for your help!

Looks like remote_transmitter is working, but remote_receiver is not. I'm debugging now, but it seems like the setup function isn't getting called? I don't understand why that would be the case. Any suggestions?

edit: I added ESP_LOGCONFIG(TAG, "Remote Transmitter Setup Complete"); to the remote_transmitter's setup function to see if it was getting called, and it looks like it isn't. (log level verbose, and other calls to ESP_LOGCONFIG are getting printed). So looks like the setup functions for these modules aren't getting called? I guess the remote_transmitter's setup function is much simpler, just sets up the pin, so the module can work without it?

more edits: I'm now realizing maybe what I'm seeing on the esphome dashboard log is actually the output from calling dump_config for each registered component? In which case I guess the missing output from the LOG call in my previous edit isn't relevant... Would the UART log show more/better information?

yeah serial log confirmed the setup is running correctly, looks like the remote_receiver loop function is exiting early because of this check:

  auto &s = this->store_;
  const uint32_t write_at = s.buffer_write_at;
  const uint32_t dist = (s.buffer_size + write_at - s.buffer_read_at) % s.buffer_size;
  // signals must at least one rising and one leading edge
  if (dist <= 1)
    return;

looks like this->store_ is filled directly from the interrupt which is attached in the setup function with

this->pin_->attach_interrupt(RemoteReceiverComponentStore::gpio_intr, &this->store_, gpio::INTERRUPT_ANY_EDGE);

are there any known issues with attaching interrupts?

[kuba2k2]

Yes, BK7231 doesn't support "any edge" interrupts, as far as I know.

[rickyelopez]

Ah, yeah that explains it. I can't find a datasheet for this chip, do you know of one?

[kuba2k2]

There is no datasheet. The only thing is a chinese PDF with pinouts, etc. No register maps or anything of sorts.

[rickyelopez]

Ah... rip. Alright, I guess I'll try to modify the remote_receiver so that it toggles the interrupt type from within the ISR

[rickyelopez]

@catalin2402's change works for me! I made a new copy of the remote_transmitter.cpp which leverages PWM on this chip, will put up a PR at some point.

[kuba2k2]

It would help to resolve the original issue if you could post the output of running bktools manually in writing mode (optionally even enabling verbose mode).

[rickyelopez]

I ended up using hid_download because I already had it set up. Does bktools work on linux? From the documentation you linked above I only see an exe download

[kuba2k2]

Yes, of course it does, it's a python tool. Don't confuse bk7231tools with BkWriter - these are different programs. You can simply install bk7231tools using pip.