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 confirms that OpenBeken support applies to the RTL8720CF-based Ameba Z2 family, including WBR3 and BW15 modules, but not to RTL8710BX, which belongs to a different AmebaZ/Ameba1 family and is unsupported by the RTL87x0C port. The port initially provides Wi‑Fi, GPIO, flash config/vars, LittleFS, WDT, OTA, and UART support, while several issues are investigated and fixed during development, including heap drain in TCP servers, MQTT authorization, PWM reboot freezes, static IP, and timing-sensitive sensor drivers such as DHT11 and DS18B20. Flashing procedures, UART pinouts, and tool compatibility are also discussed, including use of PG Tool, CH340G, and later BK7231GUIFlashTool for read/write support. The thread evolves into broader RTL87x0C port testing, Tuya config extraction, partition layout adjustments, and validation on WBR3/BW15 hardware. AI summary based on the discussion. May contain errors.
