logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda
Build faster with M5Stack »
Build faster with M5Stack » Stick • Unit • Cardputer
ADVERTISEMENT
Dostępna jest polska wersja

Czy wolisz polską wersję strony elektroda?

Nie, dziękuję Przekieruj mnie tam

NiceMCU XH-WB3S BK7238 Flashing, Testing, Pinout, Development, Porting

divadiow 18297 361
ADVERTISEMENT
Report a violation of the law
Reply | New topic
  • #31 21331460
    p.kaczmarek2
    Moderator Smart Home  
    Hmm so BL602 method works... yes, I remember adding this #if when porting OBK to BL602... but since you're saying that "settings are the same", this brings us the question, where else is the difference?

    Not that we really need to know that, since you're saying it works now, but it's interesting to know nonetheless.

    Let me know if I can help you anymore somehow, I'm very happy with the great progress you're making.
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #32 21332361
    insmod
    Level 31  
    I believe i found the cause of why flashvars aren't working. In flash_vars_read, before ddev_read(flash_hdl, (char*)data, len - 1, start_addr), len is calculated. But, somehow it is zero. So, when ddev_read tries to read with length -1, it freezes.
    A small problem is also with log. While OBK and bootloader log is redirected towards UART2, everything else goes to UART1. And it logs too much, especially if something like pwm is configured.
  • #33 21332379
    p.kaczmarek2
    Moderator Smart Home  
    First check:
    Code: text Expand Select all Copy to clipboard
    

	start_addr = flash_vars_start + flash_vars_len;

    Screenshot of source code in C language in a text editor.
    are they per page aligned?

    Added after 48 [seconds]:

    Screenshot of source code defining flash variables.
    Or are they the same ?

    Added after 43 [seconds]:

    here they are changed:
    Code: C / C++
    Log in, to see the code


    Added after 1 [minutes]:

    flash_vars_init calls bk_flash_get_info(BK_PARTITION_NET_PARAM); which may return something unexpected on your SDK?
    Helpful post? Buy me a coffee.
  • #34 21332380
    insmod
    Level 31  
    >>21332379
    Don't know yet, will try to debug
    log for now
    Code: text Expand Select all Copy to clipboard
    Debug:CFG:flash vars not initialised - reading
Debug:CFG:got part info
Debug:CFG:cleared structure
Debug:CFG:flash_vars_read len 80
Debug:CFG:flash_vars_valid()
--write status reg:0,2--
Debug:CFG:flash_vars_valid() flash open
--write status reg:7c,2--
Debug:CFG:flash_vars_valid() copied header 0xfefefefe
Debug:CFG:flash vars valid or initialised
--write status reg:0,2--
Debug:CFG:found at 1978448 0x0
Debug:CFG:ddev_read len:-1 addr:1978452
  • ADVERTISEMENT
  • #35 21332381
    p.kaczmarek2
    Moderator Smart Home  
    Also, do you get:
    Code: C / C++
    Log in, to see the code
    Helpful post? Buy me a coffee.
  • #36 21332386
    insmod
    Level 31  
    flash_vars_start and flash_vars_len should be the same, in BkDriverFlash.c partition_start_addr and partition_length are the same, as in T sdk.
    >>21332381 No, i don't
    tmp is 0
    Took a backup, and i can see, that basic flash_vars length is written correctly (0x50 at 0x1E304F and 0x1E30EF), but when reading in a loop it is zero (probably because additional 4 bytes is written after last flash var (something with alignment?))

    Added after 2 [hours] 28 [minutes]:

    Well, it is alignment failure. As soon as i added packed attribute to FLASH_VARS_STRUCTURE, it works ok. GCC/cflags problem? Default struct size for me is 80 bytes, while looking through OBK backup with hex - size is 64 bytes. Even though it works with packed attribute, size is still not 64 (71 now).

    Added after 8 [minutes]:

    Maybe time_t is 4 bytes in old gcc, while in current (i use 10.3) it is 8 bytes?

    Added after 55 [minutes]:

    Well, i changed time_t to unsigned int and now it works as expected. In the future it will probably be better to migrate to easyflash (already in sdk, no porting needed).

    Btw, i found this (volt_single_get_current_voltage) interesting function is new sdk (BK7231N only), no need for battery driver anymore?
  • #37 21332688
    p.kaczmarek2
    Moderator Smart Home  
    This makes sense. I already had this issue when doing Windows port. I had to #define:
    Code: text Expand Select all Copy to clipboard
    
_USE_32BIT_TIME_T

    I forgot that time_t is in flashvars, interesting... ah, I see, a contributor added it into ENERGY_METERING_DATA.

    So you think that:
    Code: C / C++
    Log in, to see the code

    can measure VDD? This can be easily checked, it could be useful.
    Helpful post? Buy me a coffee.
  • #38 21333355
    insmod
    Level 31  
    Well, i managed to boot it on BK7231N. Had some bumps with encryption, but managed to resolve it.
    Need to do something about rerouting logging to UART2, and to do something about binary size. Currently it is ~873kb, and this is with some features disabled.
  • #39 21333633
    p.kaczmarek2
    Moderator Smart Home  
    Interesting, what kind of features are taking that much space? Is there HTTPS support?
    I think we also still have open PR for TLS in OBK repository itself, but I didn't manage to check it yet.
    Helpful post? Buy me a coffee.
  • #40 21333709
    insmod
    Level 31  
    >>21333633 mbedtls in included in the build, so i assume yes. Also wpa3, alongside bluetooth that i can't disable.
  • #41 21333721
    p.kaczmarek2
    Moderator Smart Home  
    Well, as long as the given function is not referenced, shouldn't the linker strip it from the build? Or is WPA3 and BT in a binary blob that we can't control?
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #42 21333746
    insmod
    Level 31  
    >>21333721 BT is both binary and open source (binary libble, os is libble_pub), but if i disable it, then undefined references pop out of other binaries (librwnx, libcal etc.).
  • #43 21333839
    p.kaczmarek2
    Moderator Smart Home  
    Depending on the exact nature of the calls, it should be possible to stub them with empty functions/placeholders. I did similiar thing when doing Windows port.
    Helpful post? Buy me a coffee.
  • #44 21334165
    insmod
    Level 31  
    I written some blank functions, and it works ok, with no logs even hinting at bluetooth. Binary is also significantly smaller, even less in size than ones from tuya sdk.
    Some issues persist, like internal logging to uart1, and i also found a new one - if fast connect enabled - it may freeze.
    bk7238 and bk7231n binaries+rbl
    Attachments:
    • OpenBK7231T_App__beken_sdk_991467a7459f.zip (2.09 MB) You must be logged in to download this attachment.
  • #45 21334326
    divadiow
    Level 38  
    cool. BK7238 boot is nice to see - SDK info and stuff
    .bin from 0x0

    Code: Text
    Log in, to see the code


    OpenBK7238 user interface displaying system information
  • #46 21334391
    insmod
    Level 31  
    Solved the issue with logging to uart1, as well as freezing with fast connect on.
    Several questions: why is there a manual delay in init for BK7231N? On my temperature sensor with psk mod, i use the same method as in T (extended_app_waiting_for_launch), and it works with no problem.
    Should we keep chip temperature reading function? I disabled it, and resulting binary is about 13kb lighter.
  • #47 21334392
    divadiow
    Level 38  
    had to OTA to BK-New. QIO wouldn't boot

    Screenshot of the OpenBK7231N interface displaying device status information.
    Screenshot of the boot log for a BK7231N device, version 1.0.1, displaying processor register information.

    N boot log
    Code: Text
    Log in, to see the code
  • #48 21334555
    p.kaczmarek2
    Moderator Smart Home  
    insmod wrote:
    fast connect on.

    Do you mean OBK "fast connect" flag that just removes delay from init, or the "true" fast connect that caches... something related to WiFi?

    insmod wrote:
    why is there a manual delay in init for BK7231N?

    This is because in the old days we had some stability issues on SOME devices, and we've managed to find out with @btsimonh that adding delay between early and late init fixes the problems entirely.

    insmod wrote:
    On my temperature sensor with psk mod, i use the same method as in T (extended_app_waiting_for_launch), and it works with no problem.
    Should we keep chip temperature reading function? I disabled it, and resulting binary is about 13kb lighter.

    Depends on how tight we can make LittleFS without OTA removing it. We want to have some small default LittleFS size that is not removed by OTA (LittleFS starts at end of OTA partition), and allow users to extend LittleFS as an option by sacrifing OTA space (then OTA removes LittleFS data). Maybe add #ifdef to build to determine whether we want that?
    Helpful post? Buy me a coffee.
  • #50 21335559
    insmod
    Level 31  
    N binaries from github are still broken, but ota should still work.
    BK7231N quickly runs out of memory, triggering low heap warnings/malloc fails. Sometimes it recovers (free ram goes to ~100k), but most of the times it reboots.
    Tried new bootloader (v1.0.14), and it works... for only the first time. If rebooted - it doesn't even print anything to uart.
    Btw, discovered a way to speed up gh-actions build time. Disable submodule update in yaml, and do it in prebuild in the makefile only for specific sdk requested to build.
    Attachments:
    • OpenBK7231T_App__beken_sdk_83ee7b1d9b2d.zip (3.12 MB) You must be logged in to download this attachment.
  • #51 21335578
    p.kaczmarek2
    Moderator Smart Home  
    There is one strange issue with memory is the current, public OBK version. I don't know if it may be related, but check here:
    https://github.com/search?q=repo%3Aopenshwpro...nBK7231T_App%20lwip_close_force&type=code
    https://github.com/search?q=repo%3Aopenshwpro...%2FOpenBK7231N+lwip_close_force&type=code
    In the past we had some issues with the TCP sockets, maybe also related to the HTTP server. Basically, the threads stayed hang and the sockets wered freed. The memory allocated by each HTTP server thread was also not freed. The same (or similiar?) was observed in HTTP client.
    I've added lwip_close_force as a work around, it forces TCP socket close and frees the socket.

    I am not sure what was the main root cause, but it's certainly something to watch for.

    I also saw something similiar happen on N platform once, it was caused be weird RF partition. The HTTP server threads were stacking up and were not being freed, so each HTTP packet just increased memory usage, until malloc started to fail...

    Just sharing my old observations, not sure if it can be helpful. Good progress, @insmod, in any case
    Helpful post? Buy me a coffee.
  • #52 21335628
    insmod
    Level 31  
    Most of the time socket fails to lock a socket(?) or smth? I'm not very familiar with it's architecture.
    Web page is open, but if socks 1/20 in logs - then it will quickly runs out of memory (http server creates a thread per second?)
    If socket creates successfully, then everything is good, and i see this
    Code: text Expand Select all Copy to clipboard
    Info:MAIN:Time 243, idle 0/s, free 106376, MQTT 0(15), bWifi 1, secondsWithNoPing 180, socks 2/20 
Info:MQTT:mqtt_host empty, not starting mqtt
Info:MAIN:Time 244, idle 0/s, free 105848, MQTT 0(16), bWifi 1, secondsWithNoPing 181, socks 3/20 

    Web app log is also buggy, it hangs after a while, and, if i update the page, prints for several seconds, then hangs again.
  • #54 21335652
    insmod
    Level 31  
    >>21335644 There is a more recent fork, which is also used in lt: https://github.com/tiancj/bdk_freertos
    Interesting things in there are: wpa supplicant, which i believe is fully buildable, and can replace beken static libs, freertos v10 and open source uf2 bootloader

    >>21335628 I just refreshed web app page, and instead of app itself raw log page opened, which doesn't hang like one in web app
    I see now, why it hangs: it sometimes doesn't close the connection, and continues to receive it there (probably because connection request header is set to keep-alive)
    However now i see socks 1/20, web page open with no problems.
    If i update the index page very often (several times pre seconds), sometimes i see raw log page, instead of index one. Tried to do the same on release version - this didn't happen.
    freertos isn't cleaning up thread resources in time?
    Code: text Expand Select all Copy to clipboard
    Info:MAIN:Time 4, idle 0/s, free 95248, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 1/20 
Info:MAIN:Time 5, idle 0/s, free 95248, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 1/20 
Info:MAIN:Main_OnWiFiStatusChange - WIFI_STA_CONNECTED - 4
Info:MAIN:Time 6, idle 0/s, free 95248, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 1/20 
Info:MAIN:Time 7, idle 0/s, free 86944, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 1/20 
Info:MAIN:Time 8, idle 0/s, free 86944, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 1/20 
Info:MAIN:Time 9, idle 0/s, free 63320, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 3/20 
Info:MAIN:Time 10, idle 0/s, free 63320, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 3/20 
Error:HTTP:TCP Client is disconnected, fd: 0
Info:MAIN:Time 11, idle 0/s, free 58320, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 2/20 
Info:MAIN:Time 12, idle 0/s, free 58320, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 2/20 
Info:MAIN:Time 13, idle 0/s, free 50000, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 2/20 
Info:MAIN:Time 14, idle 0/s, free 50000, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 2/20 
Info:MAIN:Time 15, idle 0/s, free 86704, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 2/20 
Info:MAIN:Time 16, idle 0/s, free 86704, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 2/20 
Info:MAIN:Time 17, idle 0/s, free 78400, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 2/20 
Info:MAIN:Time 18, idle 0/s, free 78400, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 2/20 
Info:MAIN:Time 19, idle 0/s, free 70096, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 2/20 
Info:MQTT:mqtt_host empty, not starting mqtt
Info:MAIN:Time 20, idle 0/s, free 70096, MQTT 0(2), bWifi 1, secondsWithNoPing -1, socks 2/20 
Info:MAIN:Time 21, idle 0/s, free 61792, MQTT 0(2), bWifi 1, secondsWithNoPing -1, socks 2/20 
Info:MAIN:Time 22, idle 0/s, free 61792, MQTT 0(2), bWifi 1, secondsWithNoPing -1, socks 2/20 
Info:MAIN:Time 23, idle 0/s, free 53488, MQTT 0(2), bWifi 1, secondsWithNoPing -1, socks 2/20 
Info:MAIN:Time 24, idle 0/s, free 53488, MQTT 0(2), bWifi 1, secondsWithNoPing -1, socks 2/20 
Info:MAIN:Time 25, idle 0/s, free 86688, MQTT 0(2), bWifi 1, secondsWithNoPing -1, socks 2/20 
Info:MAIN:Time 26, idle 0/s, free 86688, MQTT 0(2), bWifi 1, secondsWithNoPing -1, socks 2/20 
Info:MAIN:Time 27, idle 0/s, free 78400, MQTT 0(2), bWifi 1, secondsWithNoPing -1, socks 2/20 
Info:MAIN:Time 28, idle 0/s, free 78400, MQTT 0(2), bWifi 1, secondsWithNoPing -1, socks 2/20 
Info:MAIN:Time 29, idle 0/s, free 70096, MQTT 0(2), bWifi 1, secondsWithNoPing -1, socks 2/20 
Info:MAIN:Time 30, idle 0/s, free 70096, MQTT 0(2), bWifi 1, secondsWithNoPing -1, socks 2/20 
Info:MAIN:Time 31, idle 0/s, free 61792, MQTT 0(2), bWifi 1, secondsWithNoPing -1, socks 2/20 
Info:MAIN:Time 32, idle 0/s, free 61792, MQTT 0(2), bWifi 1, secondsWithNoPing -1, socks 2/20 
Info:MAIN:Time 33, idle 0/s, free 53488, MQTT 0(2), bWifi 1, secondsWithNoPing -1, socks 2/20 
Info:MAIN:Time 34, idle 0/s, free 53488, MQTT 0(2), bWifi 1, secondsWithNoPing -1, socks 2/20 
Info:MAIN:Time 35, idle 0/s, free 45184, MQTT 0(2), bWifi 1, secondsWithNoPing -1, socks 2/20 
Info:MQTT:mqtt_host empty, not starting mqtt
Info:MAIN:Time 36, idle 0/s, free 45184, MQTT 0(3), bWifi 1, secondsWithNoPing -1, socks 2/20 
Info:MAIN:Time 37, idle 0/s, free 36880, MQTT 0(3), bWifi 1, secondsWithNoPing -1, socks 2/20 
Info:MAIN:Time 38, idle 0/s, free 36880, MQTT 0(3), bWifi 1, secondsWithNoPing -1, socks 2/20 
Error:MAIN:Low heap warning!
Info:MAIN:Time 39, idle 0/s, free 20272, MQTT 0(3), bWifi 1, secondsWithNoPing -1, socks 2/20 
Debug:HTTP:TCP Client 192.168.1.100:59334 thread creation failed! fd: 0
Debug:HTTP:TCP Client 192.168.1.100:59590 thread creation failed! fd: 0
Error:MAIN:Low heap warning!
Info:MAIN:Time 40, idle 0/s, free 20272, MQTT 0(3), bWifi 1, secondsWithNoPing -1, socks 2/20 
Debug:HTTP:TCP Client 192.168.1.100:59846 thread creation failed! fd: 0
Debug:HTTP:TCP Client 192.168.1.100:60358 thread creation failed! fd: 0
Error:MAIN:Low heap warning!
Info:MAIN:Time 41, idle 0/s, free 20272, MQTT 0(3), bWifi 1, secondsWithNoPing -1, socks 2/20 
Debug:HTTP:TCP Client 192.168.1.100:60614 thread creation failed! fd: 0
Debug:HTTP:TCP Client 192.168.1.100:60870 thread creation failed! fd: 0
Error:MAIN:Low heap warning!
Info:MAIN:Time 42, idle 0/s, free 20272, MQTT 0(3), bWifi 1, secondsWithNoPing -1, socks 2/20 
Debug:HTTP:TCP Client 192.168.1.100:61126 thread creation failed! fd: 0
Debug:HTTP:TCP Client 192.168.1.100:61382 thread creation failed! fd: 0
Debug:HTTP:TCP Client 192.168.1.100:61894 thread creation failed! fd: 0
Error:MAIN:Low heap warning!
Info:MAIN:Time 43, idle 0/s, free 20272, MQTT 0(3), bWifi 1, secondsWithNoPing -1, socks 2/20 
Info:MAIN:Time 44, idle 0/s, free 78400, MQTT 0(3), bWifi 1, secondsWithNoPing -1, socks 2/20 
Info:MAIN:Time 45, idle 0/s, free 51728, MQTT 0(3), bWifi 1, secondsWithNoPing -1, socks 2/20 
Info:MAIN:Time 46, idle 0/s, free 45184, MQTT 0(3), bWifi 1, secondsWithNoPing -1, socks 2/20 
Info:MAIN:Time 47, idle 0/s, free 86688, MQTT 0(3), bWifi 1, secondsWithNoPing -1, socks 2/20 
Info:MAIN:Time 48, idle 0/s, free 70096, MQTT 0(3), bWifi 1, secondsWithNoPing -1, socks 2/20 
Error:HTTP:TCP Client is disconnected, fd: 3
Info:MAIN:Time 49, idle 0/s, free 85448, MQTT 0(3), bWifi 1, secondsWithNoPing -1, socks 2/20 
Info:MAIN:Time 50, idle 0/s, free 85448, MQTT 0(3), bWifi 1, secondsWithNoPing -1, socks 2/20 
Info:MAIN:Time 51, idle 0/s, free 77160, MQTT 0(3), bWifi 1, secondsWithNoPing -1, socks 2/20 
Info:MQTT:mqtt_host empty, not starting mqtt
Info:MAIN:Time 52, idle 0/s, free 60552, MQTT 0(4), bWifi 1, secondsWithNoPing -1, socks 2/20 
Error:HTTP:TCP Client is disconnected, fd: 3
Info:MAIN:Time 53, idle 0/s, free 33984, MQTT 0(4), bWifi 1, secondsWithNoPing -1, socks 2/20 
Info:MAIN:Time 54, idle 0/s, free 25680, MQTT 0(4), bWifi 1, secondsWithNoPing -1, socks 2/20 
Debug:HTTP:TCP Client 192.168.1.100:6855 thread creation failed! fd: 0
Debug:HTTP:TCP Client 192.168.1.100:7111 thread creation failed! fd: 0
Error:MAIN:Low heap warning!
Info:MAIN:Time 55, idle 0/s, free 17376, MQTT 0(4), bWifi 1, secondsWithNoPing -1, socks 2/20 
Debug:HTTP:TCP Client 192.168.1.100:7367 thread creation failed! fd: 0
Debug:HTTP:TCP Client 192.168.1.100:7623 thread creation failed! fd: 0
Error:MAIN:Low heap warning!
Info:MAIN:Time 56, idle 0/s, free 17376, MQTT 0(4), bWifi 1, secondsWithNoPing -1, socks 2/20 
Debug:HTTP:TCP Client 192.168.1.100:8135 thread creation failed! fd: 0
Info:MAIN:Time 57, idle 0/s, free 75504, MQTT 0(4), bWifi 1, secondsWithNoPing -1, socks 2/20 
Info:MAIN:Time 58, idle 0/s, free 58896, MQTT 0(4), bWifi 1, secondsWithNoPing -1, socks 2/20 
Info:MAIN:Time 59, idle 0/s, free 83792, MQTT 0(4), bWifi 1, secondsWithNoPing -1, socks 2/20 
Info:MAIN:Time 60, idle 0/s, free 67200, MQTT 0(4), bWifi 1, secondsWithNoPing -1, socks 2/20 
Info:MAIN:Time 61, idle 0/s, free 42288, MQTT 0(4), bWifi 1, secondsWithNoPing -1, socks 2/20 
Info:MAIN:Time 62, idle 0/s, free 25680, MQTT 0(4), bWifi 1, secondsWithNoPing -1, socks 2/20 
Info:MAIN:Time 63, idle 0/s, free 74960, MQTT 0(4), bWifi 1, secondsWithNoPing -1, socks 3/20 
Info:MAIN:Time 64, idle 0/s, free 58896, MQTT 0(4), bWifi 1, secondsWithNoPing 1, socks 2/20 


    Added after 57 [minutes]:

    Looks like lwip_close_force in http server helped. Don't know if it will have any other impact.
    Edit: apparently it persists...
    By some form of magic, if i see Error:HTTP:TCP Client is disconnected
    early, then it continues to work ok

    Added after 4 [hours] 36 [minutes]:

    Several bugs remain, the most important is of course the one with stack/http server.
    Also, i noticed, sockets are not freed. I begun 105576 free stack at ~3000sec runtime with 2/20 sockets, now i am at ~6000sec and 48904 free stack with 6/20 sockets.
    I flashed this firmware at my 7231N+bl0937 plug, after first boot , it rebooted several times (probably low heap), and then it stabilized - but i noticed that loop was broken! Web/mqtt and relay toggling worked, ota worked, but no info:main log and no reboot. After physically resetting the device, can't access web (connection timeout), but mqtt works.
    Also enabled ir/c++ compilation.
  • #55 21337899
    insmod
    Level 31  
    A small update:
    Rewritten tcp server, now it is much less troublesome (at least for this sdk) https://github.com/NonPIayerCharacter/OpenBK7...ob/_beken_sdk/src/httpserver/new_tcp_server.c
    Please check if it is written correctly, and maybe later adapt it for the main branch? My free heap on BK7231N without drivers, but with mqtt on is ~100k with no leaks.
    Some time after boot, the log, will freeze, but the device will remain somewhat functional. The log will unfreeze after some time, and continue working.
    But, for about 30 minutes, log was corrupted. Then it normalized, and continued to work before i shut it down.
    Code: text Expand Select all Copy to clipboard
    Info:MAIN:Time ^T 1(3), bWifi 1, secondsWithNoPing 6314, sock^T 1(3), bWifi 1, secondsWithNoPing 6315, socks 2/20 
Info:MAIN:Time^T 1(3), bWifi 1, secondsWithNoPing 6316, socks 2/20 
Info:MAIN:Time 6^T 1(3), bWifi 1, secondsWithNoPing 6317, socks 2/20 
Info:MAIN:Tim^T 1(3), bWifi 1, secondsWithNoPing 6318, socks 2/20 
Info:MAIN:Time 6384, idle 0/s, free 102040, MQTT 1(3), bWifi 1, secondsWithNoPing 6319, socks 2/20 
Info:MAIN:Time 6385, idle 0/s,^T 1(3), bWifi 1, secondsWithNoPing 6320, socks 2/20 
Info:MAIN:Tim^T 1(3), bWifi 1, secondsWithNoPing 6321, socks^T 1(3), bWifi 1, secondsWithNoPing 6322, socks 2/20 
Info:MAIN:Time^T 1(3), bWifi 1, secondsWithNoPing 6323, socks^T 1(3), bWifi 1, secondsWithNoPing 6324, socks 2/20 
Info:MAIN:Tim^T 1(3), bWifi 1, secondsWithNoPing 6325, socks 2/20 
Info:MAIN:Time ^T 1(3), bWifi 1, secondsWithNoPing 6326, socks 2/20 
Info:MAIN:Time^T 1(3), bWifi 1, secondsWithNoPing 6327, socks 2/20 
Info:MAIN:Time^T 1(3), bWifi 1, secondsWithNoPing 6328, socks 2/20 
Info:MAIN:Time 6394, idle 0/s, free 1020^T 1(3), bWifi 1, secondsWithNoPing 6329, socks 2/20 
Info:MAIN:Ti^T 1(3), bWifi 1, secondsWithNoPing 6330, socks 2/20 
Info:MAIN:Time^T 1(3), bWifi 1, secondsWithNoPing 6331, sock^T 1(3), bWifi 1, secondsWithNoPing 6332, socks^T 1(3), bWifi 1, secondsWithNoPing 6333, socks 2/20 

    Several minutes after boot http ceases to work properly, i assume it is some problem with lwip, because some http requests manage to get a proper response. But most of the time it is either ERR_CONNECTION_RESET, ERR_EMPTY_RESPONSE, or 200 with 0 bytes response after 1s. But for those that succeeded, log entry that connection is established is shown. For those that failed, even those with HTTP 200 and 0 bytes, nothing logged.

    Added after 10 [minutes]:

    Also something is wrong with either interrupts or timings, this is what now my voltage history on bl0937 plug looks like.
    Graph of voltage on the BL0937 plug showing numerous fluctuations over time.
    I don't have RF powersave implemented yet, but it looks the same with or without mcu ps.
    On standard version, even with powersave on, it looked normal, without those spikes
  • #56 21337929
    p.kaczmarek2
    Moderator Smart Home  
    Regarding BL0937 - poweresave breaks it, but if it's not powersave, then can you look here?
    https://github.com/openshwprojects/OpenBK7231T_App/pull/1280
    @insmod this PR is stuck because I wasn't been able to verify it, but maybe you can check this out?

    I will check futher changes (server) in the morning at earliest, but I remember that I've tried to do a single-threaded server on Beken but for some strange reason it was working very poorly, slow and sluggish.
    Helpful post? Buy me a coffee.
  • #57 21338428
    insmod
    Level 31  
    >>21337929 BL0937 fix didn't solve the problem for me, still spiky. The biggest spike i got is 60kV. So the problem is somewhere else.
    Server is multithreaded by the way, but i still get some bugs, like task watchdog triggering. But it still continues to work, despite it
    Code: text Expand Select all Copy to clipboard
    task watchdog tiggered
malloc_risk
task           state   pri     water   no   
free_risk

Current task: TCP_server
task               stack_addr              top        size   overflow   backtrace
itcm_begin=3ff000 end=3ff998 flash begin=3 end=a87d0
top=40d138 bottom=40d190 size=1024 mode=1
idle               [0x40cd90 ~ 0x40d190]   0x40d138   1024   0          5753a 24c8c 
itcm_begin=3ff000 end=3ff998 flash begin=3 end=a87d0
top=414a28 bottom=414bc0 size=2048 mode=1
TCP_server         [0x4143c0 ~ 0x414bc0]   0x414a28   2048   0          914f8 9157e 915cc 919ba 923f2 36588 
itcm_begin=3ff000 end=3ff998 flash begin=3 end=a87d0
top=40dee0 bottom=40df58 size=3072 mode=1
timer_thd          [0x40d358 ~ 0x40df58]   0x40dee0   3072   0          3686c 
itcm_begin=3ff000 end=3ff998 flash begin=3 end=a87d0
top=412d70 bottom=412e30 size=2048 mode=1
tcp/ip             [0x412630 ~ 0x412e30]   0x412d70   2048   0          91418 92b26 
itcm_begin=3ff000 end=3ff998 flash begin=3 end=a87d0
top=414210 bottom=4142f8 size=4096 mode=1
wpas_thread        [0x4132f8 ~ 0x4142f8]   0x414210   4096   0          5f4d0 5e148 7eae6 81664 
itcm_begin=3ff000 end=3ff998 flash begin=3 end=a87d0
top=40f280 bottom=40f340 size=1024 mode=1
temp_detct         [0x40ef40 ~ 0x40f340]   0x40f280   1024   0          6 5da20 a6cc2 
itcm_begin=3ff000 end=3ff998 flash begin=3 end=a87d0
top=416fc8 bottom=417138 size=2048 mode=1
TCP_server         [0x416938 ~ 0x417138]   0x416fc8   2048   0          5ea68 5ea68 91406 9c6b6 3686c 91ee0 908 4e706 
itcm_begin=3ff000 end=3ff998 flash begin=3 end=a87d0
top=410370 bottom=410408 size=4096 mode=1
kmsgbk             [0x40f408 ~ 0x410408]   0x410370   4096   0          29562 
itcm_begin=3ff000 end=3ff998 flash begin=3 end=a87d0
top=41b078 bottom=41b200 size=8192 mode=1
HTTP Client        [0x419200 ~ 0x41b200]   0x41b078   8192   0          4e4fe 14c 7fe 
itcm_begin=3ff000 end=3ff998 flash begin=3 end=a87d0
top=411a98 bottom=411b68 size=2048 mode=1
core_thread        [0x411368 ~ 0x411b68]   0x411a98   2048   0          5eb92 29886 3ff1aa 

    I also removed setting the sockets as unblocking, as it's unneeded, because of using threads. This seems to improve stability, i am currently at 20 minutes runtime and most requests are accepted.
  • ADVERTISEMENT
  • #58 21341811
    p.kaczmarek2
    Moderator Smart Home  
    I got two NiceMCU_WB3S_V1:

    First key:
    Code: text Expand Select all Copy to clipboard
    
Encryption key: 84e66d00 84e66d00 84e66d00 84e66d00

    Factory dump:
    https://github.com/openshwprojects/FlashDumps/commit/1fa21aacace39914690a3e88240f371d2c471512

    Log output (on UART1, not UART2 like in BK7231):
    Code: text Expand Select all Copy to clipboard
    
  BK7238_1.0.14
REG:cpsr        spsr        r13         r14
SVC:0x000000D3              0x00401C1C  0x000033A0
IRQ:0x000000D2  0x00000010  0x00401E0C  0x7C546AA3  
FIR:0x000000D1  0x00000010  0x00401FFC  0x2468B002  
SYS:0x000000DF              0x0040192C  0x00000158  
ST:0x00000000
[I/FAL] Fal(V0.4.0)success
[I/OTA] RT-Thread OTA package(V0.2.8-beken-1133282d-20220604) initialize success.

go os_addr(0x10000)..........

www.sparkleiot.com
ready

    Second key is different:
    Code: text Expand Select all Copy to clipboard
    
84d36500 84d36500 84d36500 84d36500

    Factory dump:
    https://github.com/openshwprojects/FlashDumps/commit/696b2007d50ab08c6005799d45cf3fea2efd4810
    Helpful post? Buy me a coffee.
  • #59 21341846
    divadiow
    Level 38  
    What are your initial plans with them?

    I wonder if BK7238 will be the new BK7231N 🤔
  • #60 21341867
    insmod
    Level 31  
    I believe that encryption key efuse changed location (?) or something, because in reality all current devices with BK7238 have no encryption at all.
    Makefile in sdk uses zeroes as arguments for encryption binary.
Reply | New topic
Report a violation of the law

Topic summary

✨ The discussion centers on the NiceMCU XH-WB3S development board featuring the BK7238 SoC, initially suspected to be BK7231T but confirmed as BK7238. Users share experiences with flashing, testing, and porting firmware, including challenges with encryption keys, flash IDs, and bootloader compatibility. The BK7238 uses 2MB flash with varying encryption keys per chip, complicating universal firmware flashing. Tools like BKFIL and Easy Flasher (EF) are used for backup and restore, with EF supporting full flash erase and restore including bootloader. Flash ID support was extended to include missing flash chips to avoid CRC errors. Arduino SDK and Beken FreeRTOS SDK (version 3.0.70.1 and newer 3.0.76) are referenced for development, with partial support for BK7238 and related chips (BK7231N, BK7231U, BK7252). Porting efforts include adapting delay functions for 160MHz BK7238, resolving flashvars alignment issues due to 64-bit time_t, and addressing HTTP server and TCP socket stability problems in LWIP. OTA updates are functional but require correct image types and bootloader versions. Power save modes and their impact on peripherals like BL0937 energy meter and DS18B20 sensors are discussed, with some instability noted under power save. SPI flashing and UART flashing methods are compared, with SPI preferred for some devices. BK7231U (CC8000 chip) support is emerging, with builds available but some undefined references and boot issues. BK7252 camera module support is experimental, with encrypted flash complicating firmware use. Users report issues with DS18B20 sensor timing on BK7238 due to delay_us inaccuracies, partially fixed by new SDK delay implementations. Logging and MQTT load affect system stability and sensor reading consistency. The community shares flash dumps, toolchain links, and SDK forks to aid development and testing. Overall, the thread provides detailed technical insights into BK7238-based NiceMCU boards' flashing, SDK porting, peripheral support, and firmware development challenges and progress.
Today's popular

FAQ

TL;DR: A NiceMCU XH-WB3S board (BK7238, 2 MB flash) can run OpenBeken if you erase the whole SPI and re-flash with a CRC-fixed 7238 image; boards cost ≈ US $1.50 each and need >300 mA during Wi-Fi start-up. “Boot loops usually mean undervoltage” [Elektroda, insmod, post #21562748]

Why it matters: Correct flashing and stable power prevent endless reboots and CRC errors.

Quick Facts

• Chipset: BK7238, ARM Cortex-M33, 160 MHz [Elektroda, divadiow, post #21440151] • On-board flash: 2 MB (ID 0x852015) [Elektroda, divadiow, post #21289375] • Dev-board price: US $1–1.5 on AliExpress [Elektroda, insmod, post #21327474] • Recommended supply: 3.3 V @ ≥350 mA during TX bursts [BK72xx DS] • Default UART: 115 200 bps on P0 (UART2) [Elektroda, divadiow, post #21442320]

Why do I get endless CRC-mismatch errors when flashing?

The GUI flasher lacked the Puya 25Q16HB (ID 0x152085) entry, so the chip stayed write-protected and every sector verify failed. Update to BK7231GUIFlashTool ≥v1.9.21 or add the ID manually, then erase and re-flash [Elektroda, p.kaczmarek2, post #21342531]

Which firmware file should I use for the XH-WB3S board?

Use OpenBK7238_QIO_x.xx.xx.bin (or the .rbl OTA file) because the module really contains a BK7238, not a BK7231 [Elektroda, DeDaMrAz, post #21542280]

The board reboots every few seconds—why?

A reboot loop with only the RT-Thread banner usually means the 3.3 V rail dips below 3.0 V when Wi-Fi starts. Provide a stable ≥350 mA source or add a 470 µF capacitor [Elektroda, insmod, post #21562748]

How do I force the bootloader to accept my image?

Check “Overwrite bootloader” in the GUI, flash the CRC-fixed QIO image, then reset. On BK7238 the bootloader sits at 0x0 and refuses un-CRC’d binaries [Elektroda, divadiow, post #21550671]

What is the “No TLV header found in flash” message?

It comes from the SDK’s RF-calibration code; the first boot notices that the RF OTP/TLV partition is empty, writes defaults, then continues. The notice is harmless [Elektroda, p.kaczmarek2, post #21564311]

Why does my custom MAC vanish after reboot?

BK7238 stores the MAC in the RF-OTP/TLV area. Current OpenBeken writes it to config only; on the 7238 it must be written with manual_cal_write_macaddr_to_flash(). Until patched, the chip reloads the factory MAC on cold boot [Elektroda, p.kaczmarek2, post #21564311]

How can I enter Safe-Config mode if AP never appears?

Press or toggle RESET five times within 5 s; the bootloader starts OBK in SafeConfig, creating AP “OpenBK_xxxxxx” even with invalid Wi-Fi data [Elektroda, divadiow, post #21550706]

Power-meter readings jump by 20 V—bug or feature?

Voltage spikes on BL0937 driver occur when heavy logging or MQTT runs. Disable verbose logs (loglevel 0) or MQTT to stabilise readings [Elektroda, insmod, post #21520958]

Fast-Connect flag—what does it do?

FastConnect 1 skips full scan and uses stored BSSID/PSK. It cuts connect time from ≈3 s to 300 ms and saves ≈80 mA∙s per wake-up [Elektroda, insmod, post #21507260]

I only see garbage on UART—correct pins?

UART2 TX (module P0) outputs OBK logs at 115 200 bps. Connect RX of your adapter to P0, 3.3 V tolerant [Elektroda, divadiow, post #21550104]

Edge case: What if I flashed a BK7231 image to BK7238?

The chip shows only the bootloader banner and reboots; re-flash the correct 7238 QIO binary or full 2 MB dump via SPI [Elektroda, divadiow, post #21342237]

3-step How-To: Recover a soft-bricked XH-WB3S

  1. Erase full 0-0x1FFFFF with BKFIL (SPI needed if UART locked). 2. Flash OpenBK7238_QIO_x.bin at 0x0 with “Overwrite bootloader”. 3. Reset; join AP and finish setup—done.
ADVERTISEMENT