Description
this issue was initially opened against the STMPE610 library adafruit/Adafruit_CircuitPython_STMPE610#16
but subsequent testing has shown that it is not related to that specific library.
I was able to reproduce the same behavior with another SPI device (FRAM breakout)
First -- here is a recap of the initial issue followed by more recent findings taht hopefully help narrow down the root cause.
Issue recap:
on a feather rp2040 connected to a 2.4inch TFT featherwing (ILI9341 display) the following code has been my test program:
All code run on up to date version of CP from the latest tip of main and updated libraries
loaded as code.py
import board
import time
import digitalio
import displayio
from adafruit_stmpe610 import Adafruit_STMPE610_SPI
from adafruit_ili9341 import ILI9341
displayio.release_displays()
spi = board.SPI()
cs = board.D9
dc = board.D10
sd_cs = board.D5
ts_cs = digitalio.DigitalInOut(board.D6)
st = Adafruit_STMPE610_SPI(spi, ts_cs)
_display_bus = displayio.FourWire(spi, command=dc, chip_select=cs)
display = ILI9341(_display_bus, width=320, height=240)
print("Go Ahead - Touch the Screen - Make My Day!")
while True:
if not st.buffer_empty:
print(st.read_data())
On initial power-on or hard reset the code runs normally. If the code is stopped via a Control-C at the REPL then a soft reboot (Control-D) is issued, the code will fail to properly detect the SPI device (STMPE610)
code.py output:
Go Ahead - Touch the Screen - Make My Day!
Traceback (most recent call last):
File "code.py", line 26, in <module>
File "adafruit_stmpe610.py", line 213, in buffer_empty
File "adafruit_stmpe610.py", line 164, in _read_byte
File "adafruit_stmpe610.py", line 297, in _read_register
File "adafruit_stmpe610.py", line 293, in _read_register
KeyboardInterrupt:
Code done running.
Press an output:
Traceback (most recent call last):
File "code.py", line 14, in <module>
File "adafruit_stmpe610.py", line 283, in __init__
RuntimeError: Failed to find STMPE610! Chip Version 0x804
If another contol-D is issued, it will run normally and continue to alternate running and failing with each control-D issued...
I also found that if after the Control-C, I execute
import displayio
displayio.release_displays()
it will run normally on the next control-D
Also note that - if displayio is not initialized on the board, then the issue does not occur.
It only happens if the display is in use.
As noted above, I substituted an SPI FRAM breakout for the STMPE610 in the code above and reproduced the same issue.
This seems to exonerate the STMPE610 library (which does have it's quirks) and points to some other issue with CircuitPython.
I also verified that the issue does not occur with a feather_m4_express or feather_stm31f405 - it appears to be unique to the rp2040.
I also verified that the issue does occur with the feather_rp2040 and keyboard_featherewing.
Latest findings:
I have also found that the issue only occurs if a "control-c" is used to break out of the "while True" loop.
If it replace the "while True" with "for x in ramge(10000)"
import board
import time
import digitalio
import displayio
from adafruit_stmpe610 import Adafruit_STMPE610_SPI
from adafruit_ili9341 import ILI9341
displayio.release_displays()
spi = board.SPI()
cs = board.D9
dc = board.D10
sd_cs = board.D5
ts_cs = digitalio.DigitalInOut(board.D6)
st = Adafruit_STMPE610_SPI(spi, ts_cs)
_display_bus = displayio.FourWire(spi, command=dc, chip_select=cs)
display = ILI9341(_display_bus, width=320, height=240)
print("Go Ahead - Touch the Screen - Make My Day!")
#while True:
for x in range(10000):
if not st.buffer_empty:
print(st.read_data())
f the code runs is allowed to run until completion it will restart normally with a Control-D at the REPL.
However, if I interrupt the execution with a Control-C, then it fails as above on the next Control-D and alternates with subsequent Control-Ds as above. If allowed to complete, it always restarts on a Control-D
So, the issue appears to be related to how the system is left after a control-C interrupts the executing code.py.
I have looked at the SPI transaction with a logic analyzer but have yet to find a "smoking gun". I'll be doing more and will update with any findings.