Where to find errors and logs?

Troubleshooting
1

Hi,

I am working with a Spark Core and trying to get a Waveshare e-Paper Display (EPD) to work. I noticed that the code compiles and uploads OK to the core, and then the LED does the cyan cycles as I would have expected, but neither the Serial.print calls show anything with a particle serial monitor --follow nor do I see anything obvious on the console. If I comment out the calls to the EPD libraries then the printing starts to work OK (and the D7 LED lights up).

I am trying to learn Spark Core programming so my question is not how to get the EPD to work, but more where I should be looking for errors or logs to figure out what’s happening when the expected serial output isn’t shown. Here is the ino file.

 #include "epd1in54b.h"
 #include "imagedata.h"

 void setup() {
     Serial.begin(9600);
     pinMode(D7, OUTPUT);
     Epd epd;
     if (epd.Init() != 0) {
         Serial.print("e-Paper init failed");
         return;
     } else {
       Serial.print("e-Paper initialized");
     }

     digitalWrite(D7, HIGH);
    //  epd.DisplayFrame(IMAGE_BLACK, IMAGE_RED);
     Serial.print("Image displayed");
 }

Thanks!

2

You are using a library that’s not listed in the Particle Library repository, so you should include a link to that library if you want people to assist.
It may well be that the Epd constructor or epd.Init() block the code in a way to prevent any output.

3

I will also add that I use the serial output heavily when developing. Currently, I am working on a LED display. When I am tinkering around at work, I do not have my full LED display hooked up to the photon. Rather, it is sitting on my desk in a small bread board with just the USB cable attached. The serial output is enough to help me work through some of the animations. The output helps me verify that events are kicking off at the right time and in general, some variables are set correctly.

In your code, it is also possible that the serial output happens before you connect to the serial from your PC. I add some delay code to the setup routine so that I have a visual indicator the device is waiting a few seconds for me to run “particle serial monitor”. For example, I flash the D7 led for 1 second to indicate the beginning of the startup routine, and then go into a fast flash for 10 seconds waiting for the serial console to attach. You might consider adding something like this to your code:

//Start Serial for debugging messages.
Serial.begin(115200);

//LED Strip Initialization.
InitializeLEDStrip();

//Indicate startup via D7 LED...
pinMode(LED, OUTPUT);    // sets pin as output
digitalWrite(LED, HIGH); // sets the LED on
delay(1000);
digitalWrite(LED, LOW); // sets the LED off

//Wait for serial debugging for 10 seconds. Flash D7 for visual indication.
if (s.Debug) {
    long LastMillis = millis();
    while(!Serial.isConnected() && ( (millis() - LastMillis) < 10000 ) )
    {
        if (!LEDOn) {
            digitalWrite(LED, HIGH); // sets the LED on
        }
        else {
            digitalWrite(LED, LOW); // sets the LED off
        }
        LEDOn = !LEDOn;
        delay(200);
        Particle.process();
    }
}
digitalWrite(LED, LOW); // sets the LED off

if (!Serial.isConnected()) { s.Debug = false; } //Turn off debug messages if serial not connected.

if (s.Debug) { Serial.println(); } //Spacer...
4

If you want logging for debugging/developing purposes only, you might like to have a look at the logging mechanisms built into the system now.
This also takes care of excluding not needed logging code from your build once you disable/filter logging without all the hassle to remove/redefine or wrap in if (s.Debug)/#if ... #endif conditionals.

5

Thanks for the quick response and for the insights.

@ScruffR, I started with your insights and work in this thread and repo. In my case, I have the 1.54" Module B (B/R/W variant) of the display. So, I was starting with the arduino code that Waveshare shared on their wiki and converting by referencing the work that you had done for the 2.9" version.

I will read through the code tonight and see if I can figure out something that might be blocking the output. Based on a quick read of the logging mechanisms, I am guessing that whatever is preventing the output in this case will very likely be applicable to the serial log handler. The only other log handler that I found was for Papertrail. Are you aware of any other good log handlers?

6

I had a brief look at the 1.54" code and I guess you may be stuck in WaitUntilIdle().
How have you wired and set the BUSY_PIN?

I don’t like it when libraries assume pins, so I changed the #define statements in epdif.h to this

extern const int RST_PIN;
extern const int DC_PIN;
extern const int BUSY_PIN; 
extern const int CS_PIN;

and in the main .ino I added this

const int RST_PIN  = D5;
const int DC_PIN   = D6;
const int BUSY_PIN = D7;
const int CS_PIN   = A2;

But in my 2.9" lib I’ve opted for a constructor that takes the pin designations as parameters as well as making the used SPI interface selectable.

7

I have this display (1.54 white/black/red) and have used the Waveshare libraries with minor edits (my pinout is slightly different from @ScruffR s, see below). It works fine but the red e-ink is very, very slow and I have stopped using that color for my application.

The other bummer about these displays was pointed in that other thread: they have a lifetime limit on the number of write cycles to the display so updating the display even just every minute will cause it to reach end of life in less than a year. I have changed my code to update only every 5 minutes, but I am looking for a different technology at this point.

// In epdif.h...
#include "Particle.h"
#include "Arduino.h"

// Pin definition
#define RST_PIN         D6
#define DC_PIN          A6
#define CS_PIN          A2
#define BUSY_PIN        D5
1 Like
8

I used the same pins as your library code (Reset=A0, DC=A1, CS=A2, Busy=A4), and hard coded the values in epd1in54b.cpp and epdif.h. Assuming that the wiring is correct, WaitUntilIdle should not hold it, right?

Is it possible to “walk through” the code on Spark Core and see where it might be holding? I apologize if this sounds like a very basic question :slight_smile:

9

I had this hooked up to a raspberry pi before and saw the slow refresh. For my proof of concept the 8s refresh is OK.

Thanks for the insight on the write cycles. I will keep an eye out for it and keep the writes to a minimum.

Any chance you might have shared your code somewhere?

10

I had mine refresh every 15 minutes and just a few days ago (after half a year) magic smoke came from it (I suspect it was the FET that does the power boosting for the refresh - it now has some suspicious hump on its back :see_no_evil:)

You could, if you have something like the Particle Programmer Shield or ST-Link and some debugging tool like OpenOCD.

The reason why I suggested D7 as BUSY_PIN was to have some visual feedback to see whether the display ever gets into the non-busy state.

1 Like
11

Ah, I see. I will try D7 tonight. Thanks!

12

FYI, I finally had a chance to play around a little. Apparently, I wasn’t sending any data to be displayed. The sample is working now. Thanks for all the insights.

Time to play around with the library.

1 Like