e-Paper
e-Paper copied to clipboard
waveshareteam
stuck on DEBUG:root:e-Paper busy
By simply running python3 epd_7in5_V2_test.py, I get stuck on DEBUG:root:e-Paper busy.
Any command triggers DEBUG:root:e-Paper busy.
by simply calling init methods, I am stuck.
epd.init() or epd.Clear() won't work.
raspberry zero, e-paper 7.5in V2
@deguilardi I have the exact same issue. My hardware is identical to yours as well.
By simply running
python3 epd_7in5_V2_test.py, I get stuck on DEBUG:root:e-Paper busy. Any command triggers DEBUG:root:e-Paper busy. by simply calling init methods, I am stuck. epd.init() or epd.Clear() won't work.raspberry zero, e-paper 7.5in V2
exactly the same issue here, and with the exact model and script - the 7.5in V2
As this problem was bugging me the whole weekend I tried the same hardware (Display + HAT) with a Raspberry Pi 3B+. And all the problems were gone! The "stuck in busy state" was gone and it worked like a charm! I was also having trouble with the HAT as in running the test script was causing the Pi Zero W to reset (no idea why).
Now why is this happening with a Pi Zero W and not with a 3B+? To me it seems like because the Pi Zero W has a armv6 and 3B+ a armv7 CPU. Some of the involved software libraries or maybe even the HAT works better with (was designed for) armv7.
If this is the case Waveshare must update their documentation and really mention this issue instead of assuming that everything works in Pi Zero with the HAT.
dmesg reports:
[ 2322.191616] spidev spi0.0: setup: unsupported mode bits 8
which is SPI_LSB_FIRST
Oddly enough every other implementation than dev_hardware_SPI.c I've checked uses MSB first, same with the datasheet and user manual.
Removing the order setting at https://github.com/waveshare/e-Paper/blob/master/RaspberryPi%26JetsonNano/c/lib/Config/dev_hardware_SPI.c#L95 switches this implementation to MSB first as well, which appears to work fine with the RPi Zero W.
@sfPlayer1 Good catch! But this will fix the issue only with the C examples and not with the Python examples, right?
I think for the Python examples a Python module called spidev is used which handles the SPI operations using IOCTL through /dev/spidev0.0 . Same usage (and version) of this spidev python module works in Pi 3 B+ but not in Pi Zero W for me.
Did anyone find a solution to this problem? I also have a 7.5 inch V2 and RPI Zero. The C version of the demo works, but the Python version mostly results in DEBUG:root:e-Paper busy. The strange thing is that of the ~40 times that I tried, the Python demo worked exactly once... without me doing anything notably different (at least that I was aware of).
Interestingly, it does work with Python when connecting the board to the gpio header using the wires instead of directly putting it on top. This is less than ideal considering the extra space it takes, so I would still like to put it on top. What could cause the different behavior?
Interesting observation. The most likely explanation involves different I/O pin use, should be easy enough to measure/verify.
@sfPlayer1 I'm not sure how to measure that; can you give some pointers?
I have some more observations. With HAT on top:
- First time after power on: resets the device at
epd.init() - Second time: works and keeps working until
epdconfig.module_exit()is called - After that it is stuck in
epd.init()withDEBUG:root:e-Paper busy, even after reboot - Disconnect power and start from top
With the wires it just always works.
@kretep was the HAT working at the beginning? I observed the issue that it was working properly, but two weeks later I have the problem as described here.
@tesslinger I've had this problem since I started using it two or three days ago...
Hello everyone,
The problem of restarting at Pi ZERO is caused by our e-Paper Driver HAT. The hardware has been updated. Look at this #92
modification: This seems to be more than just a RPI ZERO restart problem.
I just verified on RPI ZERO that the code did have this problem. Python code sometimes does not work properly.
@kretep my guess appears to be incorrect, i assumed the python code may have been using different pin assignments, which you rectified by wiring it up differently.
It now seems that the wires just act as extra impedance decoupling the board from the Pi, basically acting like a small inductor and resistor. This works around the apparent stability issue in the Pi's power supply. Changing the capacitors as linked by SSYYL sounds plausible. Considering the 5V come from the external USB power supply, you may have some room for improvement there as well, i.e it may be inadequate.
That is unfortunate. I could just live with the double boot time and not call epdconfig.module_exit(), but I wonder if that is not damaging the HAT and/or rpi. Is it? I will also try some other power supplies.
I discovered same kind of problems with the 2.7" HAT, too. After power on my pi 0 often reboots in epd.init(). And after calling epd.Dev_exit() it gets stuck in epd.init(). Is it possible that it suffers from the same problem?
I have the exact same issue. Cannot run the samples on my pie 0 with the 7.5 inch V2 display.
Hello everyone,
The problem of restarting at Pi ZERO is caused by our e-Paper Driver HAT. The hardware has been updated. Look at this #92
modification: This seems to be more than just a RPI ZERO restart problem.
I just verified on RPI ZERO that the code did have this problem. Python code sometimes does not work properly.
I've bought my HAT off Amazon - do i need to replace the HAT module?
@pdavid-muc , Please try to use the PH2.0 8PIN interface. The current version only addresses the Pi Zero reboot issue, and other non-working issues are currently being tested.
@SSYYL thank you for the hint - is there a guide on the wiring? I don't know whit wire has to go to which pin.
Hello everyone,
I had the same issue for some weeks, I have bought a 7.5 inch V2 and started testing according Waveshare in Python and got stuck on "DEBUG:root:e-Paper busy". Bought then a 2.13 inch e-paper HAT for testing which worked directly :-).
Start testing with the 7.5 inch and searched the software for the busy signal without result. Just started testing all 7.5 inch versions and guess what it was a HD three color version. Details of the box > 7.5 inch V2(SKU: 13504). So it worked with the following test: sudo python epd_7in5b_HD_test.py
Good luck all and stay healthy
I have the Same issue on Raspberry Pi 3B. Haven't tested on zero or 4 since id ont have either.
Edit: Sorry, ended up being a different issue. The board wasn't coming on right.
I am getting this with the red+black 2.13 inch on a pi zero W. One thing I note is that I can run the c-code demo just fine, but python3 version and/or my own attempts at writing a short python3 demo always return 'busy'.
Hi, I did some investigation on my RPI Zero W since I had e-Paper busy issues sometimes too.
This might not apply to all issues people mention above, but I've discovered two things during my project:
- The voltage over 40 pin connector is different than if you use separate wires (5 V on connecgor vs 3.3V on wires) - BUSY signal gives 5 V signal to the RPI which might destroy pin or reboot PI. PI has 3.3 V tolerant pins, not 5 V.
- Python has 2 ms delay in reset function, which might take longer on underpowered Zero, which disconnects power for epaper and code is stuck on
e-Paper busy.
More detailed analysis on my blog https://www.martinhubacek.cz/blog/waveshare-epaper-hat-issues/
@hubmartin good catch! I finally managed to get rid of these pesky wires by redirecting the 3.3V!
September 2022 and I've just discovered this issue with my brand new 5.83" display and RPi hat. The hat is "Rev2.2" but I can't find any information about what is different. It's certainly not the RPi Zero W "e-Paper busy" issue... :/ Nowhere does Waveshare mention that RPi Zero W don't work. I don't want to have to buy another RPi to work around this issue, so what's the story?
I've tried using the 8-wire connection in stead of attaching the hat and I get the same result. Stuck forever in busy state.
Hi, I have the same problem. After few messages with waveshare support, they send a new hat. I also bought a new one, but I think the new is burned too. Or, it's my 7.5 inch B/W screen (waveshare too). It's all grey.
@kretep was the HAT working at the beginning? I observed the issue that it was working properly, but two weeks later I have the problem as described here.
Exactly the same issues years later. I'm using a Raspberry Pi 3
INFO:root:epd7in3f Demo
INFO:root:init and Clear
DEBUG:waveshare_epd.epd7in3f:e-Paper busy H
I could play with the ePaper screen for 2 weeks then it shut down for good.
One thing to mention is that the refresh was REALLY BRUTAL. Like flashing for like 5-10 seconds straight before showing an image. Could this be a faulty unit ?
My project WAS looking fine !
