[BL602/BL0937] Yet another Smart Socket 20A (but 16A)

I have bl602 with wires soldered, so will be able to test. Probably need some command to trigger infinite loop or something like that for proper testing.

I've added missing header
https://github.com/openshwprojects/OpenBK7231T_App/pull/1158/files
I can see their also have a test commands for wdt:
https://github.com/openshwprojects/OpenBL602/...components/hal_drv/bl602_hal/bl_wdt_cli.c#L55

I mean proper test by crashing socket somehow.

Added after 1 [minutes]:

Although I remembered one way, calibrating power to zero once made it freeze for me 😂. That also I should fix

I know, I was referring to compilation error.

I think I can add a "Freeze" driver that will put infinite loops in both "every second timer" and "quick tick". Usage will be:

>>21025444

I can join testing with a LF686. I am hooking it up to uart at the moment.

Here is PR to download binaries from:
https://github.com/openshwprojects/OpenBK7231T_App/pull/1158
It enables watchdog so it should just work. In order to test the watchdog, you need to start the freeze driver that just does:

So, once you confirm it just runs, you can do:

and it should just reboot with watchdog reason (unless I missed something, @miegapele can double check)

Does not seem to work, unfortunately. It boots, acts all normally, and even OTA works, but the freeze driver freezes everything and no reboot.
Might be you need to init timer too after all, will test

Let's consider the sample code again:
https://github.com/openshwprojects/OpenBL602/...components/hal_drv/bl602_hal/bl_wdt_cli.c#L55
The only thing that I seem to be missing is:


Added after 1 [minutes]:

https://github.com/openshwprojects/OpenBK7231...mits/7b570c11beebf42c04a7eee00b522a8a6931e28e

Hello guys,
I have such smart socket and successfully uploaded OpenBeken software. I was able to connect to it via web over wifi
But when I soldered out wires through which it was reprogrammed, assembled it back and put to the socket, I found it doesn't work. Led seemed to sigh and go out. Neither short nor long pressing of button did not help. Soldering up two wires just to CB2S board and connecting to PC brings it to life and to wifi again. So obviously, there some trouble with power on the socket board happened. Strange - it is totally new socket. But ok, as is now.
I suspect chip between two big capacitors (marked by red question mark on a picture (I took it from previous page, thanks)). But it is impossible to recognize it because of totally unreadable its marking.
So, maybe anyone could advise me something to bring socket to life? Or, at least, help to recognize that chip.
Thanks.

After I get this on UARL log


Loops infinitely ...

I don't know if it is important

I made same change on my branch, seems the same. everything looks frozen, but something still works. I tried forcing disconnection from the wifi, UART log then shows it trying to connect but failing.
I will try to remove wdt_feed call, seems like something is not correct.

This is suprising @miegapele because wdt_feet is at the end of OnEverySecond call:

So, with infinite loop in driver EverySecond, it should not be reached.

Hi.

epolet wrote:

I suspect chip between two big capacitors (marked by red question mark on a picture (I took it from previous page, thanks)). But it is impossible to recognize it because of totally unreadable its marking.

BP2525

epolet wrote:

Soldering up two wires just to CB2S

There shouldn't be an CB2S in this socket. It should be SM-028_V1.3

Removing wdt_feet makes it properly boot loop, after it boots in safe mode fine, so maybe worth keeping, it might help with some crashes.
ALSO that timer init code speeds up time counting by 2 so that part should not be merged.
there is slightly different time initialization in new sdk, might try that later

Raufaser wrote:

BP2525

Yep! Thank you.
I checked it and found it works well - 365V on input and 5.2V on output.
So the next stop is LM1117. It has 1.8V on input and 0.8V on output.
Strange. Between BP2525 and LM1117 there is almost nothing.
According to typical application schematic of BP2525 (let me put it here just in case) the only diode is under suspection

Ok. Will check it.

Raufaser wrote:

There shouldn't be an CB2S in this socket. It should be SM-028_V1.3

Maybe it is a little bit different version of the socket. It has CB2S :

OK. But then you are either in the wrong thread, or you flashed the wrong firmware.
CB2S has a BK7231N. This thread is about the BL602. That is a different chip.

>>21026020
Yes, strange, I see there is mutex taken on driver code, maybe it runs in parallel somehow if first one is stuck. I wonder how to test this

miegapele wrote:

Could you try without ssdp driver? ssdp generates quite a lot of traffic, might be some problems with that part.

I tried to run without SSDP driver but no joy. The device froze after circa 11-12 hours. One thing I noticed is that sometimes when it's frozen the button still works and relay can be switched manually. So it's quite inconsistent and there is no repeatable pattern.

Great work with watchdog everyone. If there are any other troubleshooting steps I could help with, please let me know.

@miegapele can you check is it ok to merge?
https://github.com/openshwprojects/OpenBK7231T_App/pull/1158
I disabled extra timer

@zdzihu123 well, if button is still working then I don't think that watchdog can help much... buttons are handled in the quick tick update. Hmm.
@miegapele what do you think?
I've seen similiar issue once or twice. It was caused by a strange TCP socket lock causing memory leak. The free memory amount was going down and memory was not freed. Finally the HTTP server code was not able to alloc new buffers for TCP connections, here:
https://github.com/openshwprojects/OpenBK7231T_App/blob/main/src/httpserver/http_tcp_server.c
If HTTP GET malloc is failing ,then device will not be reachable via HTTP but will still work when you press physical button.
See this fragment:

Maybe we could change the server behaviour to be more bulletproof? Maybe we could prealloc, let's say, 4 buffers and keep shuffling them? But that means we will be able to only handle 4 TCP connections at all... removing the "malloc" call per HTTP packet would make HTTP server immune to "malloc returns 0" problem.
There are of course some problems with that. For example, this code is shared between all platforms (well, except windows simulator), so any change there would require extensive testing. Unless we #ifdef that just for BL602...
Thoughts?

I did a lot of playing with watchdog, and it does work in the end, so should be merged.
I tested the pull request branch, it works, and OTA after that works too, so should be same to merge.
Issue was our Freeze driver was too aggressive so that it made even wdt timer not work somehow. I removed infinite loop code from Freeze_RunFrame, and modified to Freeze_OnEverySecond to do some useless calculations in infinite loop, and then it reboots as expected, and after reboot reason is shown as software watchdog.

As for freezes, I saw one while playing with wifi networks to tests one bug, but that socket runs older version.
It's also possible to freeze socket by DDOSing it with lots of http requests, but memory does not appear to be an issue to me, as far as I saw it rarely decreased much, something else looks to cause crash.
Also trying to use ping watchdog might be useful in case physical button works, but socket is not reachable through http. the same trying to disconnect socket from router if it's there. If it recovers, might indicate connection issue

Thank you, sure, so it's merged now:
https://github.com/openshwprojects/OpenBK7231...mmit/e0f7506bf2455653c51af8b5d19d59c7876ebe42
Can you submit your new "freeze" functions? Thanks!

Thank you guys, I installed .528 and will give it a shot tomorrow.

EDIT: Just out of curiosity, is that amount or events registered by BL0937 (17390 changes in 20 min) normal? Or may it be the source of my problem?

That counter is fine, it records big numbers

miegapele wrote:

As for freezes, I saw one while playing with wifi networks to tests one bug, but that socket runs older version.
It's also possible to freeze socket by DDOSing it with lots of http requests, but memory does not appear to be an issue to me, as far as I saw it rarely decreased much, something else looks to cause crash.
Also trying to use ping watchdog might be useful in case physical button works, but socket is not reachable through http. the same trying to disconnect socket from router if it's there. If it recovers, might indicate connection issue

As soon as I stopped messing with both settings page and webapp I was able to reach 48 hours uptime (and still counting). All I did was fully reflash the latest fw and stop interacting with the socket.

If the crash happens again I'll investigate further.

That counter could be hidden, it's mostly only for developers and for testing. It's related to the system of MQTT publish data culling (so the same data is not send too often).

Today at 05:00 plug was properly restarted by watchdog:

Quote:

Reboot reason: BL_RST_SOFTWARE_WATCHDOG

The only thing that's still off with BL602 seems to be internal temperature reported at 65-71c.

So we have a progress and watchdog works, that's very good! Now we still need to figure out what goes wrong... maybe we can try publishing the free memory size via MQTT to determine whether the issue is related to that?

@zdzihu123 that internal temperature is not even calibrated, I am not sure if we can use it as a reliable measurement...

Same here : Reboot reason: BL_RST_SOFTWARE_WATCHDOG
All 5 devices are still available. Nice!

@p.kaczmarek2 From time to time the Watchdog triggers a reboot. When it does, the relay switches off. That is pretty annoying. Is there a way to retain the relay state when rebooting the socket?

Have you tried the classic retain approach, just setting -1 start state in Startup tab of OpenBeken?