Customer:
I tried this and it worked for a week and then failed in exactly the same way. I restarted it and then it failed after 4 days in the same way. I’m thinking it isn’t the flat panel connector which is the problem.
I’m using a watchdog and I believe that the panel stops responding to requests and only a cold power cycle seems to resolve it. When the display is frozen like this my code kept running fine that I saw on serial output.
Is there any other way to hard-reset it in software? I need it to be running 24/7 and showing the correct information. Having it stop working like this is a big problem as I can’t trust what is on the display and I don’t know any way to work around it in software.
Originally submitted via the contact form on soldered.com on 8 October 2023. Migrated to the forum for community visibility.
Soldered Support:
Try the command esp_restart(); to maybe restart the ESP once per day at a time where the display isn’t in use so it can re-init. That resets most things in the esp. The softer version of this is esp_reboot();
I will also report this to my team to look into it as it shouldn’t happen. Could you maybe provide some more info on your project? Are you running in on battery, how often does the display refresh, is your code using a lot of memory, what’s the general idea of the project, etc. Anything helps to maybe pinpoint the source so it can be resolved.
Customer:
The project works as a secondary display for sensor status information. It is intended to be “always on” and is mounted on the wall in the office. It is powered from USB cable. I have used both regulated power supplies and PC usb ports with no apparent difference to the problem.
Once per minute it connects to a webserver and retrieves a monochrome BMP file and displays this to the screen. All of the data gathering and rendering is handled externally. Essentially it is just displaying this image on the screen.
I have previously used ESP.restart() which didn’t help but will try esp_restart() if that is a different call.
One thing to note is that even downloading new software and it triggering the reboot like that doesn’t fix the display. The only thing I have found that fixes it is removing the USB cable - cold power cycle.
From the output of the serial port I can see that my code continues to run and no errors are being detected that I can see.
I am a software engineer with 30+ years experience. I have worked a fair bit with embedded and written my own operating systems, kernel screen drivers etc, but I am fairly new to using arduino IDE. This was supposed to be a simple project.
I don’t know what could cause the display to stop updating, I don’t know if there is a two-way communication with the driver chip or if it is more fundamental than that.
Whether if the chip stopped responding this could be detected. This is why I asked about how to reset the driver chip if that is not done during a standard reboot. Is there any way to expose that low level access or some kind of health check that could tell if the display was no longer being updated?
If I could even detect the problem happening I could remotely power cycle the display. Obviously this would just be a work-around but it would meet my needs.
Soldered Support:
One question - you said the only thing that fixes it is a power cycle - what about the hardware reset button on the back of the device? Does that make the problem go away or does it specifically have to be pluggging the Inkplate in and out from power?
From what I’ve seen you’ve done a great job with checking that it’s not your code’s fault, it’s not getting stuck somewhere, but still I would like to personally inspect it. One thing that comes to mind is that a call to display.display() somehow becomes omitted or that a Wi-Fi related function somehow stops being able to get the relevant data. So, if you don’t mind me having a look at your code, I’d be happy to. Feel free to remove any specific details like links and such.
Also are you sure you’re using the latest version of the Library and the board definitions? Here’s a link which covers that: Inkplate Get Started Page — Inkplate docs documentation , this is always good to check as we make core updates to our library which can fix stuff like this. Though, Inkplate 10’s library has been quite stable from what I know but it’s worth a shot to check this.
Some info on restarting: ESP.restart() and esp_restart should be equivalent but do give the other one a try. Though, I don’t see this as a permanent solution, just more as a workaround. The driver driving the ePaper display undergoes a total software reset during a restart (the function is display.begin()) which also resets the ePaper via hardware (it has a reset pin).
Customer:
I wasn’t aware there was a hardware reset switch on the back. Can you tell me how to locate this? I can try this next time it locks up and let you know. Previously it has been wall mounted but I took it down to open the case up and reattach the connector as previously suggested.
I will clean up the code and remove the internal references and passwords etc and send it to you. Its a bit of a mess because I have tried lots of different approaches in desperation and there may be unused code etc.
I’m using version 8.1.0 of the inkplate library and I was using the board definition version 7.0.0 but I see there is now a 7.1.0 will I can try to update to see if that makes any difference as well.
Soldered Support:
It’s on the back of the PCB as a small button. Here’s where it is on the newer models of Inkplate 10. I’m unsure which model you have exactly (e-Radionica blue Inkplate 10 with touchpads or the Soldered purple Inkplate 10 without touchpads) but generally it’s in a similar place and is marked clearly as a reset button.
Sure, let me know about the code. I just think it would be the easiest way to test it and try to replicate the issue.
Attachment omitted in migration: image.png
Customer:
Mine had the 3d printed case but I see there is a small hole there.
So it crashed again and when I pressed the button through the hole it caused my software to restart but the display remains stuck with the previous data on it.
Before I did the reset I could also see that the code was waking up every minute and loading the data and reporting success etc. There is no sign of any software crash.
If I remove the power and reconnect it then that fixes it as before.
Soldered Support:
I brought this up to my colleagues today. Could you hear if there is an audible noise when the Inkplate is refreshing? Like a coil whine on the back of the board. If there isn’t such a noise, we suspect that there could be an error with the TPS ePaper power management IC.
Does the picture on Inkplate look completely normal while it’s working or are there vertical or horizontal traces or burn-in, or anything of that nature?
Feel free to send me the code still and I’ll have a look at that as well.