RTL8720DN, RTL8710B, RTL8710BX Compatibility with OpenBeken?

Question

Interesting. I have an RTL8720DN, RTL8710B and RTL8710BX. Would that cover any of those? develop once and apply to all

max4elektroda · Accepted Answer

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...

insmod · Accepted Answer

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).

p.kaczmarek2 · Accepted Answer

AT commandline?

insmod · Answer

>>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.

divadiow · Answer

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

insmod · Answer

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.

p.kaczmarek2 · Answer

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?

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.

insmod · Answer

>>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

insmod · Answer

lwip_close_force is not needed. lwip_close already uses netconn_delete,

max4elektroda · Answer

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?

insmod · Answer

>>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.

p.kaczmarek2 · Answer

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?

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.

insmod · Answer

>>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).

divadiow · Answer

expected fail on RTL8710BX from this device Code: TextLog in, to see the code different family - AmebaZ Added after 6 [hours] 52 [minutes]::) Code: TextLog in, to see the code

insmod · Answer

Managed to solve the issue with this hack in tcp server:

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).

max4elektroda · Answer

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.

insmod · Answer

set it to 1000, should be more than enough for obk.

max4elektroda · Answer

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.

p.kaczmarek2 · Answer

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

insmod · Answer

>>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).

max4elektroda · Answer

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.

divadiow · Answer

>>21347074 same, but even after flashing with PG Tool Code: TextLog in, to see the code usually OK on next boot tho

max4elektroda · Answer

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... 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 ?

divadiow · Answer

OTA fine from _rtl87x0c_102746d651c5 to 1468_merge_08bca4bd94ad. no chip temp and rbt reason

divadiow · Answer

almost true. arrived today. seems a different beast. AmebaD. Different SDK/downloader tool

p.kaczmarek2 · Answer

Nice idea, but wouldn't this OTA now brick BK7231T when fed with BK7231N RBL and vice versa?

max4elektroda · Answer

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.

p.kaczmarek2 · Answer

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:


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

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.

divadiow · Answer

BW15 bits

boot log from PA16/TX2

Log in, to see the code

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

RTL8720DN, RTL8710B, RTL8710BX Compatibility with OpenBeken?

Post #1

Post #2

Post #3

Post #4

Post #5

Post #6

Post #7

Post #8

Post #9

Post #10

Post #11

Post #12

Post #13

Post #14

Post #15

Post #16

Post #17

Post #18

Post #19

Post #20

Post #21

Post #22

Post #23

Post #24

Post #25

Post #26

Post #27

Post #28

Post #29

Post #30

Topic summary