[BK7231T] My HTTP server, configurator, MQTT support from Home Assistant

Thanks, I will check this out when I get some time on Realtek.

Right now I am actively fixing and improving OpenBeken, for example, today I added support for that kind of switch:



@kuba2k2 , since you got ATCMD demo working, can you post here a full binary and info how to run it? The one that takes UART commands and allows us to check if our flashing procedures and RTL itself are working?

p.kaczmarek2 wrote:

I am very optimistic when it comes to new chips, I already support 4 platforms - BK7231T, BK7231N, XR809, BL602 and there is a fair chance of supporting RTL and W600. It's a sign of new times for IoT cloud-cutting trend, because so far people only were desoldering non-ESP chips and replacing them with ESP modules bought on Ebay, which in my opinion is insane. Don't waste good MCUs.

Amen brother!

ExploWare wrote:

p.kaczmarek2 wrote:

I am very optimistic when it comes to new chips, I already support 4 platforms - BK7231T, BK7231N, XR809, BL602 and there is a fair chance of supporting RTL and W600. It's a sign of new times for IoT cloud-cutting trend, because so far people only were desoldering non-ESP chips and replacing them with ESP modules bought on Ebay, which in my opinion is insane. Don't waste good MCUs.

Amen brother!

The situation has already changed. With the tests I performed on my RTL setup, and with the futher confirmation from @kuba2k2 I am already confident that I will support RTL8710BN as well.

Today I found yet another chip, but at this point of time I haven't just had time to research it. It just takes really much of time to do that (remember: you can support at https://www.paypal.com/paypalme/openshwprojects ), so that one will have to wait:

The chip above is 88MW300-NAP2 and comes from YEELIGHT YLDP02YL. That was the worst bulb ever I disassembled and it might not come back in one piece:

At this point I would say "don't buy Yeelight YLDP02YL", but again, I might be wrong, I didn't take my time researching this particular bulb.

Some related search results:
https://github.com/wfr/mrvl-88mw30x-firmware-tools
https://community.home-assistant.io/t/reverse-engineering-broadlink-rm-pro-devices/85441

Wait what's this "Mi" logo doing there... This module isn't Tuya manufactured? Is it even tuya compatible?

What about these other chips, like XR809? Are these always on tuya modules, like WB2 or something?

Fix number of pins rtesults in "out of index in WEBAPP. FIX below


Change from FIX Number of Pins...
BUT: Questions...

1. Does portnumbering starts with P0 or P1 ??
2. I have seen P28 as MAX??
3. This has to be cleaned up

Dodano po 2 [godziny] 30 [minuty]:

My opject


[/i][/i]

Good catch, @theosoft , fix added. Thanks

theosoft wrote:

1. Does portnumbering starts with P0 or P1 ??

theosoft wrote:

2. I have seen P28 as MAX??

It seems you are correct




@kuba2k2 it's a Mi-home compatible light. It didn't pair with Tuya app. Product SKU code SKU411889 / GPX4002RT. Here is the attached manual:


I am creating Beken-only environment in my room. From now on, all my devices will be tested in real life usage environment. Both N and T OTA and "safe boot mode" are reliable enough that I think there is a very low chance of me bricking device remotely and being forced to attach wires again.

OK, then there are 29 GPIO for BK7231N ...

I know, I already corrected it when I read your previous post, but thanks. I based the max value on WB2S/WB3S pins and not the chip itself.

LSPA9 (CB2S + BL0942 version) English guide released:
https://www.elektroda.com/rtvforum/topic3887748.html
Learn how to flash OpenBK, calibrate BL0942 power/voltage/current sensor and how to pair with Home Assistant!

p.kaczmarek2 wrote:

What are you trying to achieve? It's encrypted.
QIO is for N, and UA is for T.
https://github.com/tuya/tuya-iotos-embeded-sd..._os/beken378/func/user_driver/BkDriverFlash.c

By the way, I will rewrite a flash vars save method soon. It has to be done to support multiple platforms smoothly. This will result in configuration loss for all users - so you will all have to reconfigure WiFi pass etc on all devices (they will become open access point if you OTA them with newer binary).

Because UART did not work for me (after several tries and questions here), I am taking the SPI writing way now.
Since my programmer is very bare metal (it asks me from which offset I start and end), I ran binwalk to see the binary structure.

Is it ok to suppose then that I can flash this (after previous backup) to my whole flash? https://github.com/openshwprojects/OpenBK7231...es/download/1.0.16/OpenBK7231N_QIO_1.0.16.bin

Apart from that, I see that you mention BL602 is supported, it means that BK7231 is capable of bluetooth pairing now or I am confusing stuff? I am interested in BK7231 bluetooth for presence detection.

Added "Config NTP Server" & "Read Flash partitions" ... maybe you can include that
diff should be diff to tag 1.0.16
some diff lines caused by CR/LF Win/Linux ...
The partition start info should be changed to platform depending DEFINES...

regards

P.S.: Woh, you changed a lot in the sources to clean up.

pepesuriano wrote:

Is it ok to suppose then that I can flash this (after previous backup) to my whole flash? https://github.com/openshwprojects/OpenBK7231...es/download/1.0.16/OpenBK7231N_QIO_1.0.16.bin

I think so, but I have never done a direct SPI flash write myself for Beken chips. @btsimonh did that at least once, he might know more about it.

pepesuriano wrote:

Apart from that, I see that you mention BL602

BL602 is a just a microcontroller like BK7231N and BK7231T. So far it works only in WiFI mode. It is useful for me because I have a RGB LED strip with BL602 and now I can pair it with my home assistant easily. As for Bluetooth, it's capable of that but there is no Bluetooth features in our app yet.


@theosoft there is at least one serious issue with your changes. The flash config structure size is not supposed to be changed. It is set to be below 2048 (if I remember correctly) to fit a certain sector on Beken and XR809 memory. I have added unused, dummy fields for future use and they can be reused, but.... but in general, more rarely used settings should be set by commands (text commands from autoexec.bat or short startup command).
Also, is one NTP url always enough or should we have a backup one?
What is the purpose of flash read? Debugging?

@theosoft take a look:


This is how most of the "rarely used" things will be configured. I am still not sure about NTP, I might include it in flash memory as you suggest, but still, the above will be most common approach.

Dodano po 1 [godziny] 45 [minuty]:

Now you can change device names in web control panel:

Meanwhile, I think I'm getting close to running a full RTL8710BN Arduino core for PlatformIO:


For now, I tested building and running code without Arduino libs (just the SDK+PlatformIO). The resulting binaries were about 26KB in size, which is surprisingly small. I will soon test out the Arduino code, some libraries (like Wi-Fi) and maybe try to debloat the SDK (from stuff like built-in "console). This should hopefully provide a small, working system for building code for this MCU.

Sooner or later, I'm also planning to include BK7231T support in my PIO platform (mainly for myself). This could provide a (finally) usable build system for these Tuya-compatible modules, totally independent from Tuya's ugly makefiles, and buildable on any platform - meaning not having to use Cygwin anymore. As my platform uses vanilla SDKs (excl. the build system), even porting OpenBeken wouldn't require porting at all Add to this the Arduino core, and we have a cross-platform HAL environment for running whatever one might want...

EDIT: I got the core to compile, and I'm currently trying to get UART working because of some "hard fault"...

Good job, have you tried OTA on RTL?

I've found another WB3S device - ZMAi-90:



I am also starting a serious testing regime (24h a day uptime expected) for all my Beken devices.

p.kaczmarek2 wrote:

Good job, have you tried OTA on RTL?

No, I'm currently trying to get basic stuff to work (like Arduino's Serial.println). Something is wrong with C++ classes here. Parent classes cause a hard fault when trying to call descendant classes' virtual methods... I have no idea what's going on as the same code compiles and works fine on Windows.

Well, first of all, you should try to narrow down the error to the shortest, reproducible case. Create again a fresh C++ example without Platform code and see when it starts to crash. Feel free to post it here, I will try to help.

But if you get bored with your classes, try to get OTA running. I would be helpful for OpenBK (or, should I rather say, OpenRTL?) users.

The thing is, that RTL sdk doesn't support C++ out of the box. Even if you write C++ code, the linker script provided by Realtek will ignore some important stuff from objective C++, like virtual classes vtables. These parts, being not included in the final binary, will compile and link properly, but crash at runtime. I have managed to add these missing linker directives (although the .ld files are massively complicated; it's impossible for me to understand it). Now, the linker complains about "undefined reference to vtable for HardwareSerial". Hopefully that's easy to fix.

I just stumbled on to OpenBK7231T from your Reddit post and got a little excited as I have a Nitebird SL1-B where the esp chip was replaced by the bk7231tqn32. (SL1 vs SL1-B)

Browsing through this post it looks like there plans to support things like this that aren't from Tuya?

The board I have does have serial pins, so I could potentially solder leads on to it and watch what's going on. I'll try to go through this post more thoroughly and see what I can do myself, but if there are any suggestions on the best path to take, that would be cool.

Hey, hello @jimbolaya , welcome to Elektroda. I will do my best to ensure that your device is supported by OpenBK!
What do you mean by non-Tuya, are you saying that Nitebird SL1-B is not a Tuya device?
I don't think that this is a problem. bk7231t should be supported in any form.


Please try to do the flashing with bkWriter, but please read the original firmware first and send it to tuya-cloudcutter guys so they can create OTA hack profile for your device (it's important so other users don't have to open the case and solder wires) https://github.com/tuya-cloudcutter/tuya-cloudcutter and remember to post here photos from the inside.

For the T version, BK7231T, you use bkWriter, here are my guides for both N and T versions:
https://www.elektroda.com/rtvforum/topic3875654.html
https://www.elektroda.com/rtvforum/topic3874289.html
https://www.elektroda.com/rtvforum/topic3880540.html


@kuba2k2 well, so try to narrow down the issue, is this only related to this class or to any other virtual classes? Vtable is a table of pointer to virtual functions used by inheritance but most likely you are already aware of that. I could try looking deeper into the issue if I had your setup at hand

If anyone's interested, I have prepared a table that lists all (known to me) Tuya wireless modules. The goal will be to outline support for each board/platform by my project.
https://github.com/kuba2k2/platformio-libretuya

Also, @p.kaczmarek2 here's the complete setup that I'm trying to get to work now. I'm not that experienced with embedded C++, so I guess I'm probably missing something obvious, like compilation flags or linker script directives. Apparently, all public SDKs for this specific MCU are made for C, so they don't really support C++. And these SDKs that do, are for a different MCU (like RTL8710**A**); yes, the numbering of these parts is completely messed up.

p.kaczmarek2 wrote:

What do you mean by non-Tuya, are you saying that Nitebird SL1-B is not a Tuya device?
I don't think that this is a problem. bk7231t should be supported in any form.

Yes, I meant that Nitebird SL1-B is not a Tuya device
Excellent!

p.kaczmarek2 wrote:

Please try to do the flashing with bkWriter, but please read the original firmware first and send it to tuya-cloudcutter guys so they can create OTA hack profile for your device (it's important so other users don't have to open the case and solder wires) <URL redacted> and remember to post here photos from the inside.

So, for the following pictures, it looks like I should be able to set it up from your posts. To be clear, I'll need two 3.3v TTL serial cables? Or do I need an SPI module of some sort?

@kuba2k2 don't forget W600 and friends. What a nice tables you have, can I borrow them and use them on my readme as well, to show which modules are supported?

@jimbolaya you should be using bkWriter 1.60 and single USB to UART converter with 3.3V logic levels.
You also must be able to power off and power on board in order to reboot it with UART to USB converter running. This will not work if you power your board directly from the same USB port, because large electrolytic capacitors takes too much current when connected to power and exceed USB specifications.
So, the suggested setup is:
- USB to UART converter with 3.3V logic levels connected to programming RX TX port
- extra 5V power supply (maybe from second USB port if they dont reset together) connected to 3.3V LDO connected to board (Beken chips are 3.3V only).
(in the past, I used slightly different method - i removed electrolityc capacitors from boards for the programming time and used 5V from the same usb port as programming, and it worked well, but only with bulk capacitor removed. Of course I soldered them back after flashing)

Procedure is:
1. start bkwriter read (first read flash to backup it)
2. power off and power on board
3. the bkwriter will do whole read after reboot of the board

The second option you have is to reboot beken with RST pin and not by power on/power off but it seems to be less reliable....
Remember to backup flash! Tuya-cloudcutter guys needs it.

WARNING: there is a small chance that flashing will not work for you at first, it happens if your board is using the RX or TX pin for button or something else. Don't worry! You can still flash it, we will just need to disconnect the button etc etc

PS: My BK7231T now controls an LCD, which is scriptable by commands:

[RTL8710]
IT WORKS!


I can't believe how stupid this problem was.
Just like I suspected, the linker script was the culprit.
The thing is, I was trying out the correct solution multiple times. And it never worked.
Why?
Because I was only modifying the linker script. The program didn't change, so PlatformIO never recompiled and relinked it. The resulting binary was always the same, no matter what I changed.
It just occured right now, that I changed something in the main program AND added correct lines to the linker at the same time. Otherwise I would be stuck with this for many more hours.

p.kaczmarek2 wrote:

@kuba2k2 don't forget W600 and friends

Are these also on Tuya modules? Or third-party chinese stuff? I only found W701-something on Tuya's site. I didn't add this to the repo as I don't know what that is.
What about BL602? Is this also a Tuya thing?

About the tables... for now, I think, I would prefer to first get my project to a working state. You can, of course, list which modules you support in OpenBeken, but IMO it would be better to have a single, self-contained "database" about all Tuya modules, 3-rd party clones, available SDK options and hacking them in general - that's my general idea of my project. This page could then point to your app, for example, or even describe flashing instructions etc. Who knows, maybe at some point we'll integrate OpenBeken with PlatformIO to create a portable environment. No pressure though, just thinking.

EDIT: tested stuff like GPIO, UART, flash ID&size, working correctly now. Tomorrow I'll try to compile libs and test Wi-Fi.

How did you manage to get so high COM port number?
For me, they are always in up to 20 range.

BL602... well, according to debug logs, it's not Tuya, but it's in smart devices that are very much like Tuya:
https://www.elektroda.pl/rtvforum/topic3881416.html#19944840
I haven't checked logs from W600 yet.

How much flash usage does the PlatformIO add?
I would be much more interested in the OTA mechanisms for Realtek platform, it's much harder than adding HAL (unless there is already a working system in SDK)

I am adding simple events system with incoming scripting features. Examples:

p.kaczmarek2 wrote:

How did you manage to get so high COM port number?

High? No, no, my other serial adapters are COM96 and COM97...
To be fair, I'm not entirely sure, but it might be related to Bluetooth devices taking like 10 ports each, and I was reinstalling BT drivers few times at some point.
By the way, you can change these numbers to whatever you want.

p.kaczmarek2 wrote:

BL602... well, according to debug logs, it's not Tuya, but it's in smart devices that are very much like Tuya:

Good thing that it's already supported by a group of reverse engineers, who wrote even an Arduino/PlatformIO core. So hey, porting your app should be a breeze.

p.kaczmarek2 wrote:

How much flash usage does the PlatformIO add?

I don't think it does. PlatformIO is just a build system - it doesn't provide its own HAL or anything. Under the hood, it uses standard vendor SDK, so programs still use the same APIs as they would without PIO. The Arduino core though, is a HAL. I ran the same code (basic Serial printing) with and without Arduino core, and they were roughly the same size (~26 KiB each). Keep in mind that Arduino added fancy Print classes, etc. Without it I had to print every number char by char...
In comparison, the vanilla SDK with all the crap inside compiles to about 300 KiB. Not cool.

p.kaczmarek2 wrote:

I would be much more interested in the OTA mechanisms for Realtek platform

As I said, I will research each part step by step. You can't get OTA without working Wi-Fi first

Why would I need to port to BL602 second time?
This platform is already almost fully supported, even with flash config save. The only thing missing is OTA.

kuba2k2 wrote:

In comparison, the vanilla SDK with all the crap inside compiles to about 300 KiB. Not cool.

Are you saying that compiler is not stripping unused functions when creating the final binary?

p.kaczmarek2 wrote:

Why would I need to port to BL602 second time?

Ah, I thought it wasn't yet worked on. My bad then.

p.kaczmarek2 wrote:

Are you saying that compiler is not stripping unused functions when creating the final binary?

Of course it is. I'm saying that the functions are always used and are not easily disabled. Even if you write your custom app, the trashy console always leaves its traces.

EDIT: I'm curious, were you able to brick a Beken in the past? I mean, can they be bricked? If yes, is it permanent or easily fixed?
If, for example, you overwrite the bootloader with a broken one, is the chip totally dead, or can it be restored via UART? (maybe python flasher?)

kuba2k2 wrote:

Of course it is. I'm saying that the functions are always used and are not easily disabled. Even if you write your custom app, the trashy console always leaves its traces.

Not easily disabled? From all my experience, the linker is not even linking the function that is not called. For example, if you have an unresolved external symbol called from a function, the program will successfully compile as long as the function itself is not referenced directly or indirectly from main () . Tested it many times.

kuba2k2 wrote:

EDIT: I'm curious, were you able to brick a Beken in the past? I mean, can they be bricked? If yes, is it permanent or easily fixed?
If, for example, you overwrite the bootloader with a broken one, is the chip totally dead, or can it be restored via UART? (maybe python flasher?)

We have discussed it with @btsimonh at the very beginning of this thread (or maybe in the first thread from the series). He was trying to do OTA in place (instead of by using secondary buffer) and bricked his BK7231T. Luckily he was able to restore it by flashing it by SPI from Raspberry Pi. I think that required tool is somewhere on OpenBekenIOT repository.

Why are you asking, do you have some BK modules?

PS: The final test of BL602 RGB led strip with Home Assistant is undergoing. Right now no stability issues found. The BL602 guide is on the way (both user guide for flashing and short programming guide for developers), first Polish version then English.

If current BL602 dev tree proves stable enough, then I will flash my BL602 port to my second BL602 device - this time it's cold/white (or maybe RGB?) LED bulb.

p.kaczmarek2 wrote:

Why are you asking, do you have some BK modules?

Yes, I said some time ago that I have WB2L.

p.kaczmarek2 wrote:

flashing it by SPI from Raspberry Pi.

My modules don't have SPI flash. Are you sure you mean BK7231T and not N or other?

p.kaczmarek2 wrote:

From all my experience, the linker is not even linking the function that is not called.

I know. But the console is somehow always there, and always running, and always useless.

kuba2k2 wrote:

My modules don't have SPI flash. Are you sure you mean BK7231T and not N or other?

You are confusing the meaning of SPI. SPI is just a protocol, like I2C or UART. Saying SPI does not imply that chip must have an external flash. It's just a port, see SPI flasher readme for details:
https://github.com/OpenBekenIOT/hid_download_py/blob/master/SPIFlash.md
You can program Beken chip by the SPI port of this chip.
From WB2S docs:

From WB2L docs (see, there is both 2x UART port and SPI port):


@btsimonh certainly did that at least once. You just connect to SPI pins of BK7231 chip (and NOT of the external flash, because there is no external flash) and it works even if UART bootloader is not present

kuba2k2 wrote:

I know. But the console is somehow always there, and always running, and always useless.

It sounds like you had the ATcmd thread running in the background. It has indeed references to all the useless stuff in the SDK. The solution is simply not to start the ATcmd thread and that's it.

p.kaczmarek2 wrote:

You are confusing the meaning of SPI.

I know what SPI is. I thought you meant writing to SPI Flash directly, hence the confusion. I didn't know that it can be flashed by SPI. Thanks for the explanation.

I'm not sure, but doesn't the BK contain an internal SPI Flash? I mean, I remember something about reading the flash ID etc, which are kind of specific to common SPI chips. Maybe it's just the internal SPI flash that's brought out in these test pins?