Would you be able to check with that line removed?
Added after 29 [seconds]:
I can also upload my tool:
My port attached. The test procedure I use is simple:
- I use read_4096 to read 4096 bytes
- then I use write_lorem_ipsum and do read again to check for lorem ipsum pattern
- then I try just erase and read to check for 0xFF
- then i try write back firmware factory version and read again
Everything works so far, but no checksum, and no flash set as mentioned.
>>21604605 I see that bootloader was flashed correctly and it works, since it prints MODULE_BOOT-LEVEL_INFO.
But it seems that OBK didn't pass checksum check. So FW2 image was used, evident by "OTA2 USE"
I didn't use rtltool for flashing, only for backup. Original flashing tool worked fine.
I am trying to get flashing working in C#, so I can integrate it with our flasher. Currently it seems that I can read and write memory blocks correctly, but without flash unprotect (if that's that I think it is). Should flashing of this BW16E work if I just directly flash OBK bin to 0x00 offset, or do I need to do something more?
[postid:d76072f7b0][/postid:d76072f7b0]
FW1/FW2 offsets are hardcoded. Bootloader then check for 81958711 signature (all realteks) (0x38 0x31 0x39 0x35 0x38 0x37 0x31 0x31).
Don't remember how it is on AmebaD, but on Z2 if it is written in both slots, then FW1 is used, if it is written in one slot only, it uses that slot, if it is written in none of them, then boot fails.
Did you convert easyflasher to interfaces? I once thought to do it for easier new platform integration, but there were too much code to be rewritten.
>>21604659 No, i meant OBK flashing tool, not config/easyflash.
Currently it is rather hard to add a new platform to it, so that's why i mentioned c# interfaces as a solution.
Ahh, sorry, I misread - I read "easyflash" and not "easyflasher". Well, don't worry about Easy Flasher, I will attempt to split it into interfaces a bit and tidy it once I get something to add there. If I manage to get this RTL write/read working now, I may do it even this week.
We will also need a name change then.
Added after 1 [minutes]:
Oh look, OBK booted.
So, to sum up:
Scenario A:
1. flash original BW16 dump
2. Flash OBK
3. No boot, as shown earlier
Scenario B:
1. Full erase
2. Flash OBK
3. OBK boots
I heard from @DeDaMrAz there are loader for different amebas - just like imgtool_flashloader_amebad.bin - would they work for other realteks with similar approach?
>>21604731 Protocol is the same (xmodem), but some things might be different (like flash protect on D is not there on Z afaik).
Z2 is a completely different animal though.
Ameba IR driver. It doesn't work for me, and i'm not sure if i didn't break beken (because converted main driver code to HALs).
It receives garbage, and doesn't output anything.
https://github.com/NonPIayerCharacter/OpenBK7231T_App/actions/runs/16249968244 irRemoteESP enabled for RTL87X0C, RTL8720D, RTL8721DA and RTL8720E.
RTL87X0C limit is 960KB, with IR it's 928KB.
I can try to test it today. We can also call @DeDaMrAz , he likes IR.
Just to be on the same page - you're aware about current IR problems, right, @insmod ? Basically, we started with Arduino-IRRemote port, which worked more or less acceptable with 50us timer, and then we realized that we have no AC protocols, so vfonov ported IRRemoteESP, but... IRRemoteESP internally used on change interrupt for ESP, and we don't seem to have that on Beken, so we converted it to 50us timer and now it seems a bit unreliable...
I also did that basic splitting of Easy Flasher code: https://github.com/openshwprojects/BK7231GUIFlashTool/commits/main/ Right now we have a base class for generic flasher and separate BK7231Flasher (obsolete name, as it supports now other BKs) and unfinished RTL flasher. So far only read works. There are still some issues, like the main form internally uses sectors (4096 bytes) and not bytes, but it's just a start..
[postid:85cf998eaa][/postid:85cf998eaa]
Change IRQ?
What about modifying interrupt on the fly?
Rising irq triggered - enable falling in callback and vice versa.
And no, i wasn't aware of IR issues, since i do not use OBK IR.
Good work on flasher.
I tried to use it with AmebaZ, but it didn't work. Tried to partially adapt pvvx amebaz rtltool to C#, but that didn't work too (i admit that i haven't really tried, just done some code changes and hoped it would work).
OpenBK7231N_amebair_ec35fc691074.rbl works the same
OpenBK7231N_ALT_amebair_ec35fc691074.rbl - Wait, it will not show ALT here? I guess not...
Same, works.
OpenBK7231N_amebair_ec35fc691074_irRemoteESP.rbl Not stable, but this is already known on main release
As far as I remember, irRemoteESP is a bit better for other protocols, so you usually need to try both to see which fits best.
AC is problematic with current implementation of 50uS timer as the strings AC requires are much longer (compared to NEC protocol ie) and timer being fixed as it is produces an error after some length of command string. We tasted this with IR2 and flipper zero at the time, hence why IR2 driver exists.
insmod wrote:
Change IRQ?
What about modifying interrupt on the fly?
Rising irq triggered - enable falling in callback and vice versa.
We had a discussion some time ago about IRQ on BK devices and I seem to remember we were lacking that in SDK (granted more than a year ago now).
Regarding this proto boarding... I've recently checked on some PCB manufacturers and it seems that it's possible to order twosided boards with shipping for a total cost as low as 5$... maybe I could dedicate some time and create a proto board for us? The only isssue is that each WiFi module has different pinout, which is problematic. I could do a CB3S +CB2S+WB3S+WB2S combo (where CB3S and WB3S are on the opposite site of the board, maybe? Just solder one?), but I am not sure about other WiFi modules. Maybe have two separate silkscreen markings? Bold for Beken and italic for RTL? Still, that would not be readable well...
But in general, I could design a board, for example, for Beken, with two soic CH340, for log and programming, with pads for related sensors, etc, for ease of prototyping.
Okay, I'm just thinking aloud, it's not the most top priority thing right now and the different pin names/placement between platforms is killing the idea. Still, it would be nice to have something in shape of Arduino but with two CH340 and space for all (most of) supported sensors, so DS18B20 (three of them on lane?), DHTs, AHTs, etc, etc.
Or maybe it would be more efficient to have one "mother board" with sensors but allow WiFi module swaps with spring contacts.
Still, it's just a random idea, for now, I'm getting back to RTL flashing work. Easy Flasher can almost flash BW16 now.
Warning: Sector header check failed. Format this sector (0x00000000).
Warning: Sector header check failed. Format this sector (0x00001000).
Warning: Sector header check failed. Format this sector (0x00002000).
Warning: Sector header check failed. Format this sector (0x00003000).
Warning: Sector header check failed. Format this sector (0x00004000).
Warning: Sector header check failed. Format this sector (0x00005000).
Warning: Sector header check failed. Format this sector (0x00006000).
Warning: Sector header check failed. Format this sector (0x00007000).
Warning: All sector header check failed. Set it to default.
EasyFlash V4.1.0 is initialize success.
You can get the latest version on https://github.com/armink/EasyFlash .
p is a pointer to string (test)
ef_set_env_blob(p, p, 4) returned 0
ef_get_env_blob(p, gettest, (uint)str.Length, &savedlen) returned 4
gettest=te,savedlen=4
C:\SourceCodes\WinEF_Test\bin\Debug\net8.0\WinEF_Test.exe (process 60368) exited with code 0 (0x0).
To automatically close the console when debugging stops, enable Tools->Options->Debugging->Automatically close the console when debugging stops.
Press any key to close this window . . .
EasyFlash port for EasyFlasher? Nice. This could really help with some issues, for example like that guy asking for longer Tasmota Device Group name that is currently inside our monolytic config structure we can't really easily change.... still, I am not sure how we will end up using EasyFlash - single call for whole config? Separate calls for separate config sections? This has to be done carefully so we dont' break compatibility often in the future.
Previous message was deleted, when i tried to post this (post length was too big)
(replaced chars with bytes, and long with int, because char in c# is 2 bytes, and long is 8 bytes)
makes me think of these https://www.ebay.co.uk/itm/166593833859, which I never did purchase. Imagine a single adaptor that could to 12F-style, CB2S, WBR3 ... 🤤
@insmod Nice, just please do not change OBK app itself behaviour at the moment, ok? We need to do migration once and well. I do not want to have separate updates blocking configs.
So, regarding potential upcoming migration - we also may need to consider adding some extra config changes, like:
- separating startup command from the config so it's not length-limited?
- separating some config sections some Tasmota Device Groups name is not limited as much as now, probably (it was requested), or just enlarging it
Does EasyFlasher work under assumption that each blob has fixed size, or will it work with variable-sized blob?
But my opinion is that this migration is not low priority, if you have pending Realtek porting, I'd say it's a bit more important, but it's obviously up to you in the end. We're here for fun.
@divadiow With the prices from offer you linked (3 euro for item, 6 euro shipping), it makes much more sense for to design a board for you, so you can order 5 pcs from China for 2$ item and 3$ shipping...
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. Summary generated by the language model.