 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: 75 |
“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: 11949 |
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: 75 |
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: 11949 |
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: 75 |
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: 625 |
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. |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2026 |
