This E9 bug scares me a lot.
I think, I have seen it as well, when implementing a QSPI with PIO, where it changes to inputs, with no pull-down (or up) enabled.
Nothing seen anymore as received (providing VDD or GND for testing input pin, inputs floating most of the time in between). I had to power cycle the board.
Similar to this report:
https://github.com/micropython/micropython/issues/15718
My questions:
Does it affect ANY GPIO, e.g. also used via peripheral devices, such as SPI (via ALT, not using PIO or GPIO bit-banging)?
Can it happen as well, when SPI as peripheral device is used and MISO becomes floating (slave does not drive, in between MISO input becomes floating)?
Or: a SPI slave device, where SCLK as input is floating (most of the time, when no SPI master selected)?
Would an external pull-up (only a pull-up, not a pull-down) help?
(actually, even I might need a pull-down, e.g. as SPI slave with SCLK as input in SPI mode 0, would a pull-up help?)
These "messages" scare me a lot:
https://github.com/raspberrypi/pico-feedback/issues/401
https://hackaday.com/2024/09/04/the-wor ... situation/
which gives me the impression: does it happen any time, with any GPIO, even for pins used in functions (ALT) like SPI?
(or when programming interfaces like QSPI, MDIO, with a floating input signal, via PIO?)
Any suggestions, e.g. using pull-up enabled (or external one) on any GPIO? (even on SPI peripheral signals?)
Or is it at the end a "show stopper", so that we had to wait for a new spin (B0, C0 version) of this chip?
What to do?
I think, I have seen it as well, when implementing a QSPI with PIO, where it changes to inputs, with no pull-down (or up) enabled.
Nothing seen anymore as received (providing VDD or GND for testing input pin, inputs floating most of the time in between). I had to power cycle the board.
Similar to this report:
https://github.com/micropython/micropython/issues/15718
My questions:
Does it affect ANY GPIO, e.g. also used via peripheral devices, such as SPI (via ALT, not using PIO or GPIO bit-banging)?
Can it happen as well, when SPI as peripheral device is used and MISO becomes floating (slave does not drive, in between MISO input becomes floating)?
Or: a SPI slave device, where SCLK as input is floating (most of the time, when no SPI master selected)?
Would an external pull-up (only a pull-up, not a pull-down) help?
(actually, even I might need a pull-down, e.g. as SPI slave with SCLK as input in SPI mode 0, would a pull-up help?)
These "messages" scare me a lot:
https://github.com/raspberrypi/pico-feedback/issues/401
https://hackaday.com/2024/09/04/the-wor ... situation/
which gives me the impression: does it happen any time, with any GPIO, even for pins used in functions (ALT) like SPI?
(or when programming interfaces like QSPI, MDIO, with a floating input signal, via PIO?)
Any suggestions, e.g. using pull-up enabled (or external one) on any GPIO? (even on SPI peripheral signals?)
Or is it at the end a "show stopper", so that we had to wait for a new spin (B0, C0 version) of this chip?
What to do?
Statistics: Posted by tjaekel — Fri Sep 06, 2024 1:33 am