For my Forth implementation for the RP2040 and RP2350, amongst other platforms, zeptoforth, I have implemented a USB CDC console in addition to the serial console. With the RP2350, but also to a much lesser extent with the RP2040, I have been experiencing an issue where transmitting data from the MCU to the host machine over USB CDC sometimes fails to actually transmit data until data is transmitted from the host machine to the MCU over the same. This occurs most frequently after only a small amount of data has been transmitted since bootup by the MCU; the more data that has been transmitted the less likely this issue will occur. Also, it occurs much more frequently with the RP2350 than with the RP2040, but I have on rare occasions observed the problem with the RP2040 as well. I have observed this problem on both the Raspberry Pi Pico 2 and the Pimoroni Pico Plus 2.
Note that the host machine is running Debian GNU/Linux trixie/sid and this issue has been observed most prominently with Web Serial with Chrome (as used by zeptocom.js) but has also occurred sporadically with pySerial, and on an even more sporadic basis with picocom. I have also another user confirm that this issue formerly occurred with zeptocom.js under Chrome on the RP2350 (but not the RP2040), but I do not know what operating system they were using offhand.
With zeptocom.js under Chrome I implemented a workaround where I only buffer very small amounts of data at a time (i.e. now I am using a buffer of a mere 16 bytes where formerly I was using a buffer of 65535 bytes), and this greatly ameliorates the issue with it. I do not see how the RX buffer size on the host side would affect data transmitted by the MCU side (which I confirmed through sending logging messages to the host machine over serial) failing to be acknowledged by the host side until the host side transmits data to the MCU side.
Then there is the question of why the RP2350 is affected so much more than the RP2040. The RP2350 is supposed to be fully backwards-source-compatible with the RP2040 with regard to USB, register addresses, bitfield offsets, and the fact that the PHY_ISO bit needs to be cleared after bootup and powerdown events ─ however, if any of these were the issue, it should not work at all, rather than only sporadically fail, and in a fashion dependent on host RX buffer size and like.
I have tried things like futzing with the LINESTATE_TUNING register (even though it is recommended that this be left as-is) to no avail. I have also attempted making every change I could think of to the zeptoforth internals thinking that it may be a zeptoforth bug dependent on the RP2350 versus the RP2040, also to no avail. At this point I am left wondering if this is really just an obscure hardware bug in the USB implementation on the RP2350.
For the record, my source code of my USB CDC console implementation is at https://github.com/tabemann/zeptoforth/ ... rth/usb.fs.
Note that the host machine is running Debian GNU/Linux trixie/sid and this issue has been observed most prominently with Web Serial with Chrome (as used by zeptocom.js) but has also occurred sporadically with pySerial, and on an even more sporadic basis with picocom. I have also another user confirm that this issue formerly occurred with zeptocom.js under Chrome on the RP2350 (but not the RP2040), but I do not know what operating system they were using offhand.
With zeptocom.js under Chrome I implemented a workaround where I only buffer very small amounts of data at a time (i.e. now I am using a buffer of a mere 16 bytes where formerly I was using a buffer of 65535 bytes), and this greatly ameliorates the issue with it. I do not see how the RX buffer size on the host side would affect data transmitted by the MCU side (which I confirmed through sending logging messages to the host machine over serial) failing to be acknowledged by the host side until the host side transmits data to the MCU side.
Then there is the question of why the RP2350 is affected so much more than the RP2040. The RP2350 is supposed to be fully backwards-source-compatible with the RP2040 with regard to USB, register addresses, bitfield offsets, and the fact that the PHY_ISO bit needs to be cleared after bootup and powerdown events ─ however, if any of these were the issue, it should not work at all, rather than only sporadically fail, and in a fashion dependent on host RX buffer size and like.
I have tried things like futzing with the LINESTATE_TUNING register (even though it is recommended that this be left as-is) to no avail. I have also attempted making every change I could think of to the zeptoforth internals thinking that it may be a zeptoforth bug dependent on the RP2350 versus the RP2040, also to no avail. At this point I am left wondering if this is really just an obscure hardware bug in the USB implementation on the RP2350.
For the record, my source code of my USB CDC console implementation is at https://github.com/tabemann/zeptoforth/ ... rth/usb.fs.
Statistics: Posted by tabemann — Sun Oct 27, 2024 9:32 pm — Replies 0 — Views 34
