logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

RTL8720DN, RTL8710B, RTL8710BX Compatibility with OpenBeken?

divadiow 38736 408
ADVERTISEMENT
Report a violation of the law
Reply | New topic

  • Flash tool now supports RTL8720DN and RTL8710B/BX

    #1 21346440
    divadiow
    Level 38  
    Posts: 5213
    Help: 446
    Rate: 914
    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!
    eufyMake E1 - łatwa personalizacja za pomocą druku UV [sponsorowany]
  • ADVERTISEMENT
  • #2 21346701
    insmod
    Level 31  
    Posts: 1432
    Help: 168
    Rate: 455
    >>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: 5213
    Help: 446
    Rate: 914
    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.
  • #4 21347048
    insmod
    Level 31  
    Posts: 1432
    Help: 168
    Rate: 455
    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.

  • Suggesting socket timeout and forced close fixes

    #5 21347065
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14755
    Help: 659
    Rate: 12881
    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: 1432
    Help: 168
    Rate: 455
    >>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: 758
    Help: 49
    Rate: 189
    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?

  • RTL87x0c branch adds wifi, OTA, and UART support

    #9 21347147
    insmod
    Level 31  
    Posts: 1432
    Help: 168
    Rate: 455
    >>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.

  • Windows-based auto-refresh flasher utility in progress

    #10 21347570
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14755
    Help: 659
    Rate: 12881
    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.
  • #11 21347578
    insmod
    Level 31  
    Posts: 1432
    Help: 168
    Rate: 455
    >>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).

  • RTL8710C boot log shows OpenBeken starts successfully

    #12 21347611
    divadiow
    Level 38  
    Posts: 5213
    Help: 446
    Rate: 914
    expected fail on RTL8710BX from this device https://www.elektroda.com/rtvforum/topic4032920.html

    Code: Text
    Log in, to see the code


    different family - AmebaZ

    Added after 6 [hours] 52 [minutes]:

    :)

    Code: Text
    Log in, to see the code


    OpenRTL87X0C user interface with configuration and restart buttons
  • Helpful post
    #13 21348153
    max4elektroda
    Level 24  
    Posts: 758
    Help: 49
    Rate: 189
    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...

  • Forcibly aborting TIME_WAIT sockets to free heap

    #14 21348648
    insmod
    Level 31  
    Posts: 1432
    Help: 168
    Rate: 455
    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: 758
    Help: 49
    Rate: 189
    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.
  • ADVERTISEMENT
  • #17 21348793
    max4elektroda
    Level 24  
    Posts: 758
    Help: 49
    Rate: 189
    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.

  • Questions TCP_MSL timing and OTA compatibility

    #18 21348859
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14755
    Help: 659
    Rate: 12881
    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.

  • OTA build with UART commands disabled

    #19 21348913
    insmod
    Level 31  
    Posts: 1432
    Help: 168
    Rate: 455
    >>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.

  • Reducing TCP_MSL and planning OTA support

    #20 21348972
    max4elektroda
    Level 24  
    Posts: 758
    Help: 49
    Rate: 189
    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: 5213
    Help: 446
    Rate: 914
    >>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.

  • Proof of concept for LN882H support in PR#1466

    #22 21349569
    max4elektroda
    Level 24  
    Posts: 758
    Help: 49
    Rate: 189
    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: 1432
    Help: 168
    Rate: 455
    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: 5213
    Help: 446
    Rate: 914
    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.
  • ADVERTISEMENT
  • #26 21355631
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14755
    Help: 659
    Rate: 12881
    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: 758
    Help: 49
    Rate: 189
    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.

  • Compile-time filename prefix check for OTA images

    #28 21355787
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14755
    Help: 659
    Rate: 12881
    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.

  • BW15 boot log shows RTL8710C platform and UART2 flashing pins

    #29 21357446
    divadiow
    Level 38  
    Posts: 5213
    Help: 446
    Rate: 914
    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: 14755
    Help: 659
    Rate: 12881
    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

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