logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

RTL8720DN, RTL8710B, RTL8710BX Compatibility with OpenBeken?

divadiow 31233 392
ADVERTISEMENT
Report a violation of the law
Reply | New topic
  • #1 21346440
    divadiow
    Level 38  
    Posts: 4844
    Help: 421
    Rate: 853
    insmod wrote:
    Then i will try to port to rtl8720c


    Interesting. I have an RTL8720DN, RTL8710B and RTL8710BX. Would that cover any of those?

    Added after 6 [minutes]:

    "develop once and apply to all"

    https://www.amebaiot.com/en/ameba-sdk-summary/



    Update 2026
    As of 2026, this platform read/write is also supported by our flash tool:
    https://github.com/openshwprojects/BK7231GUIFlashTool
    The connection (soldering, wires), is the same, but you can use our tool instead of the legacy one.
    Please check it out and use it instead of legacy tools, let us know how it works for you!
  • ADVERTISEMENT
  • #2 21346701
    insmod
    Level 31  
    Posts: 1353
    Help: 160
    Rate: 425
    >>21346440 Nope, i'm using BW15 module, which is RTL8720CF. Maybe sdks are compatible, then it should work on any of those. Do you have a WBR3 module? It is also RTL8720CF based.
    I have more or less done the initial port. Wifi works (but damn, it connect in the same thread in which it was called, blocking it), flash config/vars (had to port easyflash), lfs, basic gpio.
  • #3 21346711
    divadiow
    Level 38  
    Posts: 4844
    Help: 421
    Rate: 853
    insmod wrote:
    Do you have a WBR3 module

    nope, but I started research as soon as you said ;)

    was looking at a BW15.

    Added after 3 [hours] 23 [minutes]:

    went for a module
    Screenshot of an order for a BW15 Ble 4.2 WiFi Wireless Module with low power consumption, priced at £1.32.
  • ADVERTISEMENT
  • #4 21347048
    insmod
    Level 31  
    Posts: 1353
    Help: 160
    Rate: 425
    I encountered the same problem, as with tr6260. Memory is slowly drained with pages open, until it stabilizes.
    If 2 pages opened, and one of them is closed - free heap slowly increases (by about 20k per page). 168 bytes is freed per second.
    Can't find a cause for this. Present in both tcp servers for me.
  • #5 21347065
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14399
    Help: 650
    Rate: 12329
    Maybe try shortening the lifespan/keepalive of a socket?
    Maybe it's related to HTTP header content-length, do we even parse it? Maybe we should force-close socket after parsing whole HTTP packet?

    Just speculating, how do you flash BW15? I'll check if I have one

    Added after 59 [seconds]:

    At which point in tcp_client_thread it stucks? Maybe lwip_force_close? Does it stuck before processing the packet or after?

    Added after 57 [seconds]:

    What if we rewrite the server to hold a linked list (structs with next/prev) of current requests and their time of arrival and force-kill (with mutex) requests that are stuck for longer than let's say 1 second?
    Helpful post? Buy me a coffee.
  • #6 21347074
    insmod
    Level 31  
    Posts: 1353
    Help: 160
    Rate: 425
    >>21347065 ltchiptool worked for first flashing, but on later tries rtl stopped booting with [MISC Err]Hash Result Incorrect!
    Now i flash with https://github.com/Ameba-AIoT/ameba-rtos-z2/b...mebaZ2/Image_Tool/AmebaZII_PGTool_v1.2.47.exe
    Threads are not stuck, everything continues to work.

    Added after 1 [minutes]:

    Current binary
    Attachments:
    • flash_is.bin (669.82 KB) You must be logged in to download this attachment.
  • ADVERTISEMENT
  • #8 21347138
    max4elektroda
    Level 24  
    Posts: 745
    Help: 47
    Rate: 183
    Just another idea: is this issue present with all pages?
    Index page is requesting state regularly.
    Is memory also draining if you e.g directly call cfg page?
  • #9 21347147
    insmod
    Level 31  
    Posts: 1353
    Help: 160
    Rate: 425
    >>21347138 cfg page is also requesting state, as is any page that is not the web app. Web app is requesting log, so situation is identical to index page.

    Added after 10 [hours] 8 [minutes]:

    https://github.com/NonPIayerCharacter/OpenBK7231T_App/tree/_rtl87x0c
    What should work: wifi, config, wdt, pins, lfs, ota(hacky, but works), uart (only default one, didn't bother with uart1/2 yet).
    Based on top of https://github.com/openshwprojects/OpenBK7231T_App/pull/1462
    Need someone with a wbr3 tuyamcu device to test it.
    Heap problem remains.
    Attachments:
    • OpenBK7231T_App__rtl87x0c_aa4cdfb3de9a_OpenRTL87X0C.zip (851.11 KB) You must be logged in to download this attachment.
  • #10 21347570
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14399
    Help: 650
    Rate: 12329
    I may have one, I've did some experiments in the past:
    WBR3 module with wires held in hand against a background of a box with LED strips.
    I need few moments, and I'll check precisely which modules of this series I have and try to flash them.


    PS: @insmod , I am working on an utility, that you might find useful. I want to do something like "Auto refresh and flash new" like in PICKIT2 flasher. Basically, you will be able to select a PR from drop down list and utility will wait for PR update and automatically flash the new binaries when they show up on Github. At the moment I have made a proof of concept binaries download from Github:
    Screenshot of a folder containing application files and ZIP archives.
    If I may ask, are you using Windows?
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #11 21347578
    insmod
    Level 31  
    Posts: 1353
    Help: 160
    Rate: 425
    >>21347570 Windows for everything but compilation, those i do in WSL2.
    WBR3 is RTL8720CF, as is BW15. Any RTL C is supported (Ameba Z2 family).
  • Helpful post
    #13 21348153
    max4elektroda
    Level 24  
    Posts: 745
    Help: 47
    Rate: 183
    insmod wrote:
    cfg page is also requesting state, as is any page that is not the web app.

    I just made PR#1464 as a "quick hack" to avoid loading state if the according div is not present.
    On a first glance it does what I intended: No more loading of "index?state=1" if not on main page...
  • #14 21348648
    insmod
    Level 31  
    Posts: 1353
    Help: 160
    Rate: 425
    Managed to solve the issue with this hack in tcp server:
    Code: text Expand Select all Copy to clipboard
    void CleanTimeWaits()
{
   while(tcp_tw_pcbs != NULL)
   {
      tcp_abort(tcp_tw_pcbs);
   }
}

    This will forcibly close all sockets in TIME_WAIT state, therefore freeing the memory. I am now at 3 minutes of 2 simultaneously opened web pages with ~90k free heap.
    Should i do this, or maybe change TCP_MSL in each affected sdk? Default is 2 minutes, change it to semething like 5 seconds?
    In BK N TCP_MSL is defined to TCP_TMR_INTERVAL, which is 250 (ms).
  • #15 21348763
    max4elektroda
    Level 24  
    Posts: 745
    Help: 47
    Rate: 183
    I would vote for reducing the wait time.
    The general rule was wait at least two times MSL iirc.
    I can't imagine the total time between endpoints is 2 minutes. Even if we talk about Internet resources and not LAN devices involved.
    So lowering MSL should be a good idea from my point of view.
  • #17 21348793
    max4elektroda
    Level 24  
    Posts: 745
    Help: 47
    Rate: 183
    We might do this for other platforms, too (most default to 60000).
    This should generally reduce memory usage, since it's not only used with HTTP but all TCP connections like MQTT, NTP.
  • #18 21348859
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14399
    Help: 650
    Rate: 12329
    How exactly this TCP_MSL works? Is it a time since last activity, or a time since connection handshake?

    Remember that we have this old "HTTP OTA" mechanism on many platforms that works by sending HTTP GET to given IP and downloads OTA file this way. I hope the new change won't break it?

    Are those PRs ready to merge?
    https://github.com/openshwprojects/OpenBK7231T_App/pull/1465
    https://github.com/openshwprojects/OpenBK7231T_App/pull/1464
    https://github.com/openshwprojects/OpenBK7231T_App/pull/1462

    PS: I've started working on a OTA tool. It will be both GUI and commandline. The idea is to just specify the PR link (or commit) and a device (or list of devices) and tool will automatically flash them to binaries from given PR/commit: https://www.elektroda.com/rtvforum/topic4093378.html
    Helpful post? Buy me a coffee.
  • #19 21348913
    insmod
    Level 31  
    Posts: 1353
    Help: 160
    Rate: 425
    >>21348859 Don't know, but i believe since server closed the socket.
    Shouldn't break anything, since i changed it only on ESP and TR6260, and beken already uses 250.
    Both of my prs should be ready, but i wouldn't mind if someone tested hal one on more devices. It works on TR6260 and RTL, and shouldn't break anything, but still.

    Added after 29 [minutes]:

    New build, this one should have fully working OTA.
    Additionally disabled uart commands (sadly it didn't reduce the binary size).
    Attachments:
    • OpenBK7231T_App__rtl87x0c_102746d651c5_OpenRTL87X0C.zip (847.08 KB) You must be logged in to download this attachment.
  • #20 21348972
    max4elektroda
    Level 24  
    Posts: 745
    Help: 47
    Rate: 183
    TCP_MSL is the maximum time TCP expects a packet to live in network.
    Though defined somewhere to be 2 minutes, this is a base to calculate how long to keep a connection in wait before closing a socket.
    Since we have a limited usage of the system an usually are in LAN, it should be safe to reduce this time if it will reduce resources needed.
    E.g. in W800 it's also set to 1000ms.

    Added after 9 [minutes]:

    p.kaczmarek2 wrote:
    PS: I've started working on a OTA

    I had the same idea when inspecting the code for the LN882H issues, but no time yet.
    The tricky part should be only to make sure the correct image is used, the only needed "functional code" should be HTTP POST the image to the ota address if I'm not missing anything.
  • #21 21349497
    divadiow
    Level 38  
    Posts: 4844
    Help: 421
    Rate: 853
    >>21347074
    same, but even after flashing with PG Tool

    Code: Text
    Log in, to see the code


    usually OK on next boot tho
    Screenshot of AmebaZ2 PG Tool 1.2.47 showing boot load errors and flashing settings.
  • #22 21349569
    max4elektroda
    Level 24  
    Posts: 745
    Help: 47
    Rate: 183
    max4elektroda wrote:
    I had the same idea when inspecting the code for the LN882H issues, but no time yet.

    You can find the basic idea as a "proof of concept" in PR#1466.
    It's only basically tested with LN882H for now, so use with caution...

    Screenshot of a user interface for OTA firmware update. Screenshot of a web application interface for OTA updates with a message about no file selected.

    Added after 1 [hours] 8 [minutes]:

    Since it's not related to the RTL boards, maybe this should be better moved to another thread @p.kaczmarek2 ?
  • Helpful post
    #23 21350196
    insmod
    Level 31  
    Posts: 1353
    Help: 160
    Rate: 425
    https://github.com/openshwprojects/OpenBK7231T_App/pull/1468
    Added PWM (untested, especially when 2 pins share the same pwm channel), alternate uart (both tested with tuyamcu simulator), reboot reason, powersave and current firmware index (1 or 2).
    Disabled displaying/sending chip temperature for devices that doesn't support it (rtl/tr6260/xr809).
  • #24 21350263
    divadiow
    Level 38  
    Posts: 4844
    Help: 421
    Rate: 853
    OTA fine from _rtl87x0c_102746d651c5 to 1468_merge_08bca4bd94ad. no chip temp and rbt reason

    Screenshot of the user interface of OpenRTL87X0C_F3BBD20A displaying system status information.
  • #26 21355631
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14399
    Help: 650
    Rate: 12329
    max4elektroda wrote:

    You can find the basic idea as a "proof of concept" in PR#1466.

    Nice idea, but wouldn't this OTA now brick BK7231T when fed with BK7231N RBL and vice versa?
    Helpful post? Buy me a coffee.
  • #27 21355696
    max4elektroda
    Level 24  
    Posts: 745
    Help: 47
    Rate: 183
    p.kaczmarek2 wrote:
    wouldn't this OTA now brick BK7231T when fed with BK7231N RBL and vice versa?

    Sure, same potential to do something wrong as the field above on the page: if you request a wrong image from the server in the URL, you can do exactly the same. At least if I got it right that BK flashing code doesn't do any checks of the image. All other platforms seem to to some sanity check of the image to flash.
  • #28 21355787
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14399
    Help: 650
    Rate: 12329
    EDIT: Ignore it, OTA discussion is now there: https://www.elektroda.com/rtvforum/topic4094306.html
    Spoiler:
    As far as I remember, BK7231 code does checks for the RBL image, but they do not check the N or T flavour. So the only "dangerous" combination is putting T RBL on N or vice versa.

    So we need the tiniest possible check, for example, do an universal check for filename start, see if it matches, idk, current platform #define, then I can merge it.

    Like:
    Code: text Expand Select all Copy to clipboard
    
httpprintf(request,"if(file.name.startsWith(\"%s\") {", SOME_DEFINE_HERE)

    If you put expected filename prefix at compile time, it will still be lightweight but it will check well for current platform
    Helpful post? Buy me a coffee.
  • #29 21357446
    divadiow
    Level 38  
    Posts: 4844
    Help: 421
    Rate: 853
    BW15 bits

    boot log from PA16/TX2

    Code: Text
    Log in, to see the code


    Illustration of BW15 module with pin labels.
    Close-up of two electronic modules with labeled pins.

    Not sure what the firmware that came with the module is at this point. It doesn't broadcast an AP.

    flashing with PA15/PA16 and PA00 to 3.3v

    Screenshot of the OpenRTL87X0C software interface displaying system information.

    Image of the Bity BW15 electronic module with visible connectors and pin labels. B&T BW15 module with technical markings.
    Attachments:
    • BW15_bkup.bin (2 MB) You must be logged in to download this attachment.
  • Helpful post
    #30 21357466
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14399
    Help: 650
    Rate: 12329
    divadiow wrote:

    Not sure what the firmware that came with the module is at this point. It doesn't broadcast an AP.

    AT commandline?
    Screenshot of a hex editor showing data and error messages related to AT command lines.
    Helpful post? Buy me a coffee.
Reply | New topic
Report a violation of the law

Topic summary

✨ 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.
Today's popular
ADVERTISEMENT