I'm using the Sparkfun SerLCD (4x20) and it's working well driven over SPI from my Argon.
I've noticed however that if I cloud flash a new firmware to the Argon, the LCD screen goes haywire and doesn't recover after the Argon reboots. The only way to recover the situation is to power-cycle the LCD...after the LCD reboots, it immediately recovers and is fine again. This is fine on the bench, but not fine in the field.
Note that since I only have a single SPI device that I'll talk to for this project, I've hard-wired C/S on the LCD to low (always on)... and possibly this is part of the problem and/or solution.
I'm looking for any experience or suggestions on this...
Do I need to shut-down SPI when a flash comes in so I can start it back up again without power-cycling the LCD? I'm not exactly sure why the LCD goes bonkers in the first place. (maybe if I were driving c/s properly it would help? I don't want to lose a gpio pin and pull that extra wire)
Is there something I should do when starting up that will reset SPI or the LCD to sync up again? I don't think there's an EN pin on the lcd that would allow me to reset it vi GPIO.
What would a recommended way be to power-cycle the LCD with pins? The LCD draws 40mA, too much for GPIO to power directly - so I could use one of those mosfet breakout boards and use GPIO to low/high a mosfet to power cycle the LCD...but that's a lot of extra parts and wiring and seems like it's not addressing the real problem, if it's addresable.
I suggest hooking up the CS pin. Also make sure you don't have Ethernet enabled in the configuration flash. If you have Ethernet detection enabled, at boot the Argon will probe with SPI bus looking for the Wiznet W5500. Without a CS line, those commands will go to your display. But it's possible that it's something else that's accessing the SPI bus other than Ethernet.
If your display doesn't have a hardware reset line, a MOSFET would be a good choice for powering 40 mA if you do need to reset the display.
It is possible to be notified before an OTA reset, but since you don't really have anything that you can turn off, that won't really help.
So, here's a vid with CS permanently tied low and here you see the display renders correctly until reset, and it seems to go off the rails just after the reset button is pressed (I added System.disableFeature(FEATURE_ETHERNET_DETECTION); to my setup() and had no effect). Power cycle resolves until next reset.
Here's a vid with C/S tied to D2, and here we see that it survives reset without completely losing the display, but switching the C/S line hi-low introduces these whacky block characters. I also observed that a single block character would occur if I manually ground C/S as well - so def C/S going hi/low is causing these characters.
Here's a scope trace of C/S and this looks ok to me so I don't see this as an electrical. Opinions?
Ok - I think I figured it out. Driving CS hi/low is required to survive resets cleanly, but there is a UART RX pin on the lcd which needs to be held low to prevent floating voltages from corrupting the display when using SPI. There is a tech note on this behavior, but it's poorly written in that it clubs a lot of different use cases together into a single note but doesn't specify which interface methods it applies to (UART/SPI/I2C). [ I'm currently driving it with i2c as a test, and this rx pin behavior doesn't seem to apply there, even across resets ]
