I've noticed NTP sync is pending on your device and I've seen it somewhere else doing the same, does it eventually sync or not? If not workaround I found was to add a 5-10 second delay before NTP driver start.
@p.kaczmarek2 and @insmod
Just a ping on NTP driver not starting on some devices, sorry not sure which but I'll check.
It is on W600 with FW 1.18.131 will test after OTA to new version
OTA on 1.18.135 done, without delay on startDriver NTP
Opened pull req EF for flasher
https://github.com/openshwprojects/BK7231GUIFlashTool/pull/59 Not working. Reading ends up with CRC error. Writing - CRC error on device.
Main problem is CFG offsets - pinsState_t should be 2 times the size on RTL8720D (64 pins instead of 32).
Move to unsafe cfg, like i've done earlier in EF demo?
Added Floaders (AmebaD, AmebaD_New, AmebaDplus, AmebaLite, AmebaZ, AmebaZ2) in base64 format.
Default AmebaD floader works. New one from ameba-rtos doesn't work. It gets flash id successfully, but doesn't read anything (command api changed?)
Nice, but quick question - does it break compatibility?
I am hoping to find enough time to add LN882H flashing tomorrow or later upcoming week, so I want to have your changes merged, but I don't want them to break existing config of OBK at the moment.
[postid:d469f422f4][/postid:d469f422f4]
It shouldn't. I changed almost nothing in what was already there.
Only OBKFlashLayout.getConfigLocation started returning sector count as an out variable.
Everything else was either in RTLFlasher or behind RTL8720DN check.
I'm not sure if writing config in tandem with firmware would work, since erase is not done for config specifically.
Hm, i've just done successful rest ota on RTL8721DA from fw1 to fw2 and vice versa.
There were no problems.
I've wiped the flash before flashing though.
SPI LED works on DA. So, the only realteks that are broken are A and B.
My main problem with ota was that for some reason what passes into ota function contains http header. Why??
Wait, what? OTA data with HTTP header? But... you mean before my changes, right? Currently I'm just splitting OTA into hal files, because this large function in rest_interface.c is not readable.
You can check what is wrong by taking a backup first with flashed via rest, second with http and run binary comparison between them.
good shout.
other machine Win/Chrome no diff
Added after 11 [minutes]:
Linux/FF no diff. If it's on proper wifi I get checksum error and so no reboot and no brick.
If on Windows AP I get OTA success and brick on reboot. Not had a problem with either AP type with other devices. Weird. Will do backup of difference on Windows AP after brick and HTTP method success
Any other platform that need SPI LED support?
Realteks all work, from RTL_A to RTL_E. I didn't test long led strips with high led count, only a ring with 12 leds.
+ breaking change for esp8266, added 3 missing pins (io9, io10 and io16).
Updated docs to include IR status.
✨ The discussion centers on the compatibility and support of Realtek RTL8720DN, RTL8710B, and RTL8710BX chips with the OpenBeken firmware and SDK. The RTL8720CF-based modules (e.g., BW15, WBR3) are confirmed to be supported by the AmebaZ2 family SDK and OpenBeken ports, with functional WiFi, GPIO, flash configuration, OTA, UART, and basic peripherals. However, RTL8710BX and RTL8710B (AmebaZ family) present challenges such as WiFi initialization freezes, memory management issues, and incomplete SDK support, including lack of static IP and WiFi scanning. OTA updates are functional but have occasional reboot issues, especially on RTL8710B. PWM support is mostly stable after fixes, while MQTT required patching due to missing authorization code in the Realtek LWIP stack. Power-saving modes and sensor drivers (DHT11, DS18B20) have been tested with varying success across platforms. Flashing RTL modules requires specific UART converters (e.g., CH340G) and careful wiring; some modules need manual pin pulls and special flashing tools like AmebaZ2 PGTool. TuyaMCU and energy metering ICs (BL0937, BL0942) support is under active development and testing, with UART and GPIO interrupt methods used. Memory partitioning for configuration, LittleFS, and Tuya config extraction is being optimized to avoid overwriting user data. Static IP implementation required workarounds due to sscanf inconsistencies on RTL and related platforms. A UART-to-TCP bridge driver has been developed for some modules. Overall, RTL8720CF modules have good OpenBeken support, RTL8710B is progressing but unstable, and RTL8710BX remains problematic. The community is actively testing, fixing, and improving support for these Realtek chips within OpenBeken and related tools. Generated by the language model.
