zeptoforth long time to "boot up" on rp2040 MCU

[circuit4u-medium]

I uploaded zeptoforth-1.4.1 to RP2040. Somehow the web based terminal windows doesn't connect, though the virtual serial port does appear in the browser dialog box.

Then I tried to connect with tera-term. It does eventually show the ".ok" message, but after 2 minutes of non-responsiveness.

Is this typical, or I have issue with my setup?

[tabemann]

I presume you are a Windows user as you are using Tera Term. I normally am a Linux user, and I have no such issues under Linux with the exception of that Chrome does not like to connect to a tty device that I have connected previously to with something other than Chrome or GNU Screen. However, when I tested out zeptoforth under Windows, not using USB but rather using a serial dongle, it took forever for Windows to see my serial dongle. I have not really heard of such issues from other Windows users though.

Note that it is normal for zeptoforth to take a few seconds even under Linux to show up as a tty device when using USB, and if you have freshly flashed a board with zeptoforth it will take a moment to register because it is erasing unused flash. However, I have not tried zeptoforth on all RP2040 boards, and they do differ in the flash chips used, and some flash chips are faster than others I have found. A good test would be to boot zeptoforth up until the point it displays ok, and then power cycle it without re-flashing it, and see if it boots faster the second time around. If it does load faster the second time, try re-flashing your RP2040 board; if it is slow again, then it is an issue with your RP2040 board (they do differ in the QSPI flash chips that are used, and some are faster than others; it could just happen that yours may be very slow to erase), but if it is still fast then I suspect it is a Windows virtual COM port issue. If it is slow the second time around, it may be either a device issue or a Windows virtual COM port issue; in that case, I would suggest getting ahold of a bog standard Raspberry Pi Pico if you can, flashing that, and attempting to connect to it with a virtual COM port; I know for certain there are not issues with support for the Pico, so if it is slow to connect to that then it is almost certainly a Windows virtual COM port issue.

[circuit4u-medium]

Thanks for the detailed analysis. It does seem to be a Windows machine issue. Since the majority of the users are Linux users, this isn't going to be a big issue.