You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
7.2.4 and some earlier versions have a problem with GPIO0 being used for board.UART() on the Feather RP2040. The following program will hang and then USB will disconnect after 10 iterations, due to the gc.collect().,
This is related to #6213 and was found after fixing that bug by setting ringbuf->buf to NULL in ringbuf_free().
If GPIO0 is changed to another TX-capable UART0 pin, then the problem does not happen. I have looked for some issue about the pin->number being zero being treated specially, but haven't found it yet.
The text was updated successfully, but these errors were encountered:
This is affected by whether or not the TX and/or RX pins are connected to another board. I was testing with them connected to a QT Py RP2040 that was not powered. TX->RX, RX->TX, and common ground. Without the connection, I don't see the failure. To be continued.
So I don't think it's GPIO0 per se, it's that GPIO was connected to something.
Rework the ADC implementation to follow the improved ADC/ADCBlock API.
This adds support for calibrated voltage readings and the ADC2 block. The
ADC API is backwards compatible with what it was before this change.
Resolvesadafruit#6219.
7.2.4 and some earlier versions have a problem with GPIO0 being used for board.UART() on the Feather RP2040. The following program will hang and then USB will disconnect after 10 iterations, due to the
gc.collect()
.,This is related to #6213 and was found after fixing that bug by setting
ringbuf->buf
to NULL inringbuf_free()
.If you remove the early gc.collect(), it hangs later, when a gc is necessary, after about 867 iterations or something like that.
The default pins for
board.UART()
are (frommpconfigboard.h
):If
GPIO0
is changed to another TX-capable UART0 pin, then the problem does not happen. I have looked for some issue about thepin->number
being zero being treated specially, but haven't found it yet.The text was updated successfully, but these errors were encountered: