 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : Patched Webmite 6.04.00RC1 WeAct RP2350B Wifi
| Author | Message | ||||
| Gerad Regular Member  Joined: 10/01/2024 Location: GermanyPosts: 78 |
“WebMiteRP2350V6.04.00RC1_RM2.uf2 file fixes the Wi-Fi problem. See Patch Report. It works with WeAct & RM2 and Pico2 W. Not with Waveshare RP2350B-Plus-W. Manual, page 81 describes the Problem "With some routers it can take some time or a couple of attempts to connect, so if you are using OPTION AUTORUN ON, it would be worth inserting something like this at the very start of your program: DO WHILE MM.INFO(IP ADDRESS) = "0.0.0.0" IF TIMER > 5000 THEN CPU RESTART LOOP This would wait 5 seconds for a connection and restart if still not connected." WebMite_RP2350B_RM2_WiFi_Patch_Report.pdf WebMiteRP2350V6.04.00RC1_RM2.zip Edited 2026-10-06 02:20 by Gerad |
||||
| matherp Guru  Joined: 11/12/2012 Location: United KingdomPosts: 11956 |
I will analyse this further but, for the avoidance of doubt, this is a Fritzbox specific issue or at least I'm not aware of any reports on a non-Fritzbox router. I can type cpu restart forever on my network and it will always re-connect. I'm unclear why the patch limits to rp2350 only as presumably the rp2040 has the same issue? |
||||
| Gerad Regular Member Joined: 10/01/2024 Location: GermanyPosts: 78 |
I'm having the same problem with the RP2040, which is why I'm using a “do while...” loop. Maybe it's a “Fritzbox” issue. But in Germany, that's pretty much the norm. Still, after 2–3 connection attempts, the connection is established. Edited 2026-10-06 03:30 by Gerad |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 11956 |
I will implement the retry code but not the soft reset change. It isn't safe when called from an interrupt. SoftReset() is called from the 1 ms timer callback, for the WATCHDOG timeout and the hang-detection timer (PicoMite.c:2433, PicoMite.c:2439). cyw43_arch_deinit() must not run from an interrupt: the SDK's own check panics there (async_context_poll.c:49). In a release build that check is off. The network stack is then shut down from inside an interrupt that may have arrived in the middle of a network call. If that crashes, the hardware watchdog hasn't been started yet, so the board hangs instead of restarting. WATCHDOG exists to get a stuck board running again, and this would make it hang. In any case, the driver already does this: every cyw43_arch_init() drives WL_REG_ON low for 20 ms, then high, then waits 250 ms (cyw43_bus_pio_spi.c:360). |
||||
| dddns Guru Joined: 20/09/2024 Location: GermanyPosts: 915 |
I have seen the same behavior as with a Fritzbox with an ESP01S module running ESP-Link acting as AP. |
||||
| Gerad Regular Member Joined: 10/01/2024 Location: GermanyPosts: 78 |
Peter Of course, you're absolutely right. That was just some leftover software from when I was trying to figure out why the connection wasn't working. It's been removed in "WebMiteRP2350V6.04.00RC1_RM2_V1.uf2" WebMiteRP2350V6.04.00RC1_RM2_V1.uf2.zip WebMite_RP2350B_RM2_V1_Technical_Report.pdf |
||||
maxwelloau Newbie  Joined: 31/10/2025 Location: AustraliaPosts: 6 |
While this may be an unrelated or another modem problem (either way extremely minor in my opinion) it is closely related to what is being reported (I think). This is provided just for extra information, but happy if you disregard it! I have observed that once wifi is connected its 100% bullet proof. On every CPU RESTART it always fails the first wifi connection. A cpu restart is initiated anyway, and wifi connection always occurs on the 2nd attempt. Equipment. TPlink DECO X50 mesh unit 2.4 wifi and 5 wifi (pico mac address is configured to use only 2.4 wifi and only the closest unit, and mesh is disabled for this mac address. RP2350 Pico 2W genuine, configured with static IP details AU. In the main router DHCP server, the mac address will only use a reserved IP address, 192.168.1.200. (same as the static IP in the Pico, tried both ways, same result). Doing a WEB SCAN after the first boot and after the second boot there is a huge difference in reported WIFI strength. I have observed the connection quirk over all V6 and V7 firmware. Is this a firmware or an internal module hardware timing thing I ask myself, with very little actual knowledge in this area! --------------------MMCC logging--------------------------------------- 14:53:23] finished 3844 (running program, total # pings since WIFI restart) [14:53:28] > CLEAR [14:53:33] > CPU RESTART [14:53:37] 14:53:37 Port: COM5 removed Disconnected 14:53:38 Port: COM5 inserted Connected to COM5 at PicoM connecting to WiFi... [14:53:44] failed to connect. [14:53:54] Timeout - Reboot [14:53:55] 14:53:55 Port: COM5 removed Disconnected 14:53:55 Port: COM5 inserted Connected to COM5 at PicoM connecting to WiFi... [14:54:01] Connected 192.168.1.200 [14:54:11] Reply from 1.1.1.1: seq=1 time=11.648ms [14:54:11] Ping statistics for 1.1.1.1: sent=1 received=1 lost=0 average=11.648ms [14:54:11] finished 1 [14:54:21] Reply from 1.1.1.1: seq=1 time=11.958ms [14:54:21] Ping statistics for 1.1.1.1: sent=1 received=1 lost=0 average=11.958ms [14:54:21] finished 2 [14:54:24] > ------WEB SCAN after connected + then WEB SCAN before connected----------- PicoM connecting to WiFi... [15:07:56] Connected 192.168.1.200 [15:07:59] > [15:07:59] > [15:08:00] > web scan [15:08:03] [15:08:03] Performing wifi scan [15:08:03] ssid: tweedle rssi: -40 chan: 8 mac: b0:19:21:3c:3f:86 sec: 5 [15:08:03] ssid: tweedle_Guest rssi: -40 chan: 8 mac: ba:19:21:3c:3f:86 sec: 5 [15:08:03] ssid: tweedle_IoT rssi: -41 chan: 8 mac: be:19:21:3c:3f:86 sec: 5 [15:08:03] ssid: rssi: -71 chan: 8 mac: b6:19:21:3c:3f:82 sec: 5 [15:08:08] > cpu restart [15:08:09] 15:08:09 Port: COM5 removed Disconnected 15:08:09 Port: COM5 inserted Connected to COM5 at PicoM connecting to WiFi... [15:08:15] failed to connect. [15:08:16] > web scan [15:08:19] [15:08:19] Performing wifi scan [15:08:19] ssid: tweedle_Guest rssi: -84 chan: 5 mac: ba:19:21:3c:6e:8a sec: 5 [15:08:19] ssid: tweedle_IoT rssi: -86 chan: 5 mac: be:19:21:3c:6e:8a sec: 5 [15:08:19] ssid: tweedle rssi: -72 chan: 8 mac: b0:19:21:3c:3f:82 sec: 5 [15:08:20] ssid: rssi: -38 chan: 8 mac: b6:19:21:3c:3f:86 sec: 5 [15:08:25] > |
||||
| ville56 Guru Joined: 08/06/2022 Location: AustriaPosts: 626 |
Interestingly all APs have different channels after reboot. I think they should be the same except they all have repeaters for their SSIDs. Then this may happen but is strange anyway as there are big differences in the RSSI values before and after reboot. Don't know what the PRI RF hardware is capable (automatic attenuators?) 73 de OE1HGA, Gerald |
||||
| maxwelloau Newbie Joined: 31/10/2025 Location: AustraliaPosts: 6 |
Wow a blinding fast change to test. I believe it is heading in the right direction Peter. After FW update to 7.0b6, first load, no wifi, 2nd boot wifi ok. Amended the basic program to perform the ping, wait then do a CPU RESTART. Now 50% average result. That is, after a reboot where wifi is good, 2nd reboot is failed. On a DC power cycle first boot seems to always fail, then ok on the next RESTART. Again I caution that nothing else is affected by the change, and this quirk is not taking valuable time from something else. Due to the short cycle I noticed not accepting incoming pings! Modified basic to ping out, wait 10 seconds. Repeat this 4 times. (total 5 pins out) Then CPU RESTART. Even with this it works like a toggle switch on CPU RESTART! wifi connection, wifi fail, wifi connection, wifi fail. Ping incoming slow to work, taking 3.5 to 5 periods. Hope this is useful but it is ok to tell me where to go, what to do too! Maxwelloau. |
||||
| ville56 Guru Joined: 08/06/2022 Location: AustriaPosts: 626 |
Compared to the actual release V7.00.00 RC6 there is no change in the behaviour at network connect in a wifi network controlled by a Fritzbox router. Every 2nd time it reliably fails. Maybe the network connect should have a retry counter with, say, 3 retries. Otherwise we will have to stay with the already proven solutions. They are IMHO not beautiful but at least they work. WEB SCAN is not delivering reliable results at all. The scan periode seem to be too short to list all networks available at any given time. The RSSI values do vary abt 10 dB here, which is IMHO acceptable. As the internal circuitry for measuring the RSSI and the level control is probably not very sophisticated and results may be rather coarse. Gerald 73 de OE1HGA, Gerald |
||||
| Gerad Regular Member Joined: 10/01/2024 Location: GermanyPosts: 78 |
9. Detailed patch behavior Initial result value: connect_result is initialized to PICO_ERROR_CONNECT_FAILED only so it has a defined value before the loop. Each loop iteration immediately replaces it with the real join result. Maximum of three joins: rm2_attempt runs from 1 through 3. This matches observed behavior on similar WebMite systems where two or three attempts can occasionally be required. Success path: If the join returns 0, the loop exits immediately. The original WebConnect() success logic then continues unchanged: WIFIconnected is set, LastWifiErr becomes 0, and TCP/TFTP/UDP services are opened as configured. WebMite RP2350B + RM2 - RM2 V1 | 6 Selective retry: A retry happens only when connect_result equals PICO_ERROR_CONNECT_FAILED. Authentication errors and other error classes are not blindly retried. One-second settle interval: Between failed -8 attempts, cyw43_arch_poll() is called 100 times with 10 ms between calls. This lets the polling-based CYW43/lwIP context process pending work instead of simply sleeping. Final failure behavior: If all three attempts return -8, or another non-retriable error occurs, control falls through to the original WebMite failure handling. The patch does not bypass or replace the existing error logic. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 11956 |
Sorry, but I am not making any more changes. Web connection is completely reliable for most people and I can't remote diagnose specific local issues. Previously changes went in which fixed Jim's Fritzbox issues and I have added the retry loop for -8. That is it. Anything else will have to be coded individually in Basic |
||||
| Gerad Regular Member Joined: 10/01/2024 Location: GermanyPosts: 78 |
I have two FritzBoxes on my network. I no longer have any connection errors with WebMite. With ESP (Arduino), I also use three connection attempts. Everything works. |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2026 |
