BSoM Cellular Connect when used with Epaper Display

[peekay123]

@friedl_1977, that looks like a single blink Hard Fault.

• Which EPD library are you using?

Also, you are doing way too much in myHandler() which I assume is your subcription handler. Handlers are run after loop() completes and should not block. In your case you call a number of cloud functions at the end of the handler which can be problematic (e.g. waitUntil()). Cloud disconnects and cellular control should be handled in an FSM in loop() so as not be blocking (as suggested by @robc ). The FSM states would step through the actions necessary to do what you need:

@friedl_1977

• Connect and Get Stuff
• Wait for stuff and send to screen
• do the same again....

Another note is that it is considered best practice to use specified-length copy commands to prevent buffer overruns. In your case, use strncpy() instead of strcpy() for copying data in myHandler().

[friedl_1977]

Hi @peekay123

@peekay123

Which EPD library are you using?

I am using the official one recommended by WaveShare for this specific panel. It is the epd4in2b_V2 one.

@peekay123

Also, you are doing way too much in myHandler() which I assume is your subcription handler. Handlers are run after loop() completes and should not block.

Just for some clarity. I have commented out just about every thing on the handler which yielded the same results. I will do this again just to test. Programming is most certainly not my one of my hidden talents (hehe) so let me rather confirm, but I do recall commenting this out.

For more information: I have stripped this code down tho the bare minimum. A basic function connecting the modem and then a function only initializing the screen, not even running the code updating the screen or subscribing to the webhook. After disconnecting once, the modem still fails to reconnect.

I will attempt this very minimum sketch again and post my results. Thank you for the input, I really appreciate it as I have no idea what else to try.

EDIT: Something else. if I call the EPI init function in SETUP before anything else, the modem fails to connect even if it is the very first thing happening after setup. My reasoning was that the handler could to have affected it in this case as the webhook was never called due to the modem not being able the connect. I might be wring of course.

Regards, Friedl

[peekay123]

So, generally, the pins are connected as follows. I am not sure which of the D pins are assigned to which EPD pin (DC/RST/BUSY).

B524 Pin #	B524 Pin Name	EPD Pin
48	SPI (SS)	CS
52	SPI (MOSI)	DIN
54	SPI (SCK)	CLK
68	D5	DC/RST/BUSY
70	D6	DC/RST/BUS
72	D7	DC/RST/BUS

Can you share your bare minimum code? What else is connected on the SPI port used by the display?

[friedl_1977]

Hi @peekay123

@peekay123

Can you share your bare minimum code?

Sure no problem. Please see below:

#include "Particle.h"

SYSTEM_MODE(SEMI_AUTOMATIC);
SYSTEM_THREAD(ENABLED);

//SerialLogHandler logHandler(LOG_LEVEL_TRACE);

#include <SPI.h>
#include "../lib/EPD4_2/src/imagedata.h"
#include "../lib/EPD4_2/src/epdpaint.h"
#include "../lib/EPD4_2/src/epd4in2b_V2.h"

unsigned long previousMillis1 = 0;          // NTC timer
unsigned long currentMillis1 = 0;
unsigned interval1 = 60000; 

Epd epd;

#define COLORED     0
#define UNCOLORED   1

#define HALO D11                            // AUX Pin - Master On/Off button
#define BATON D22                           // Battery Connect pin
#define LDO_EN D23                          // EN Pin for GDM regulator
    
int new_end_point_STATE = 0;
int current_end_point_STATE = 0;
    
char data[10] = "data";                     //default data
int Handler_STATE = 0;
    
void setup() {

  Serial.begin(115200);

  Particle.subscribe("hook-response/get_data", myHandler, MY_DEVICES);
  Particle.setDisconnectOptions(CloudDisconnectOptions().graceful(true).timeout(5s));
    
  pinMode(BATON, OUTPUT);
  digitalWrite(BATON,HIGH);
    
  pinMode(LDO_EN, OUTPUT);
  digitalWrite(LDO_EN, LOW);

  delay(1000);

  Serial.println();
  Serial.println("Initializing e-Paper display");

    if (epd.Init() != 0) { 
      Serial.print("Failed to initialize display");
      return;
      }

   Serial.println(epd.Init());
}

void End_Point() {

  Serial.println("Calling End Point function..."); 
      uint32_t freemem = System.freeMemory();
      Serial.print("free memory: ");
      Serial.println(freemem);
      delay(100);
      epd.Sleep();

   if (Particle.connected() == false) {
      Serial.println("IF Statement executing");
      delay(50);
      digitalWrite(LDO_EN, HIGH);
      delay(50);
      Cellular.on();
      Serial.println("test1");
      waitFor(Cellular.isOn, 60000);
      Serial.println("test2");
      Particle.connect();
      Serial.println("test3");
      waitFor(Particle.connected, 60000);
      Serial.println("test4");
      }

    Particle.publish("get_data", data, PRIVATE);
    new_end_point_STATE = 1;                                 
}

void myHandler(const char *event, const char *data) {

  Handler_STATE = 1;
  //new_end_point_STATE = 2;

}

void EPD() {
  
  // Serial.println();
  // Serial.println("Initializing e-Paper display");

  //   if (epd.Init() != 0) { 
  //     Serial.print("Failed to initialize display");
  //     return;
  //     }
}

void loop() {
    
currentMillis1 = millis();

   if ((currentMillis1 - previousMillis1 >= interval1) && (new_end_point_STATE == 0)) {
     previousMillis1 = currentMillis1;
     End_Point();
      } 

   if (Handler_STATE == 1) {    
      Particle.disconnect();                                                 // Use only in SEMI_AUTOMATIC mode
      waitUntil(Particle.disconnected);
      Cellular.off();
      waitUntil(Cellular.isOff);
      delay(10);
      digitalWrite(LDO_EN, LOW);
      Serial.println("LDO Disconnected");
      Handler_STATE = 0;
      new_end_point_STATE = 0;
      }

  // if (new_end_point_STATE == 2) {
  //       EPD();
  //     }    
}

Just ran this now again. With the INIT call in the Setup, the modem does not connect al all, remains breathing dark blue. If I remove this from setup() and run it from the function only after webhook response, the modem connects the first time, but on the second connection attempt, it is stuck in the same breathing blue state.

@peekay123

So, generally, the pins are connected as follows

My pinout below:

Pin 48 - CS
Pin 52 - DIN
Pin 54 - CLK
Pin 68 - DC
Pin 70 - RST
Pin 72 - BUSY

@peekay123

What else is connected on the SPI port used by the display?

Nothing. Just have some I2C sensors on the board as well. As I mentioned, I also ran the same code on the BSoM evaluation board, with a 4.2" Epaper module (screen on their own PCB) connected via the SPI connectors. Get the same result even with nothing else attached.

Thank you for the interest in helping out.

[chipmc]

@friedl_1977 ,

This is a tough one. The SOS code you are getting is a hard fault and they are hard to diagnose.

From the Particle docs:

Some causes of hard fault include:

• Using an invalid pointer.
• Memory corruption caused by freeing memory twice, overwriting the end of a block of memory, etc.
• Making Wire (I2C) calls without calling Wire.begin().

Since you are running minimal code, I wonder if you would be open to trying a different library (if your specific panel is supported). I used this library with a WaveShare ePaper and did not have any issues:

GxEPD2_PP | Reference

Worth a try?

Chip

[friedl_1977]

Hi Chip -

Let me just reiterate that fact that I am a very entry-level programmer at best For sure I would be open to try a new library and after two weeks of trying to make this work, the only conclusion I can come up with is indeed a problem in the current library.

I can reduce that minimal code even more... you can strip away everything and just leave the INIT call in the setup. The same problem persists.

If I run in Automatic mode, I sometime get 2-3 'successful' epaper updated before it hard faults.

Thanks again, I will try this today and revert back.

Regards, Friedl!

@chipmc

I used this library with a WaveShare ePaper and did not have any issues:

Just curious, did you use this with B-series? I am using B-524 for development, but will replace it with B404x as the client in is US.

[chipmc]

@friedl_1977 ,

My experience was with the Boron but, I do have some near-term plans to start working with the B-524.

Thanks,

Chip

[friedl_1977]

Hi Chip -

I will see whether I can get the other library to work and revert back to give you my findings.

I asked someone else (much more clued up in programming than me) this morning to also have a look. They could get it to work either

[peekay123]

@friedl_1977, I agree with @chipmc on trying the GxEPD2_PP library. The Waveshare library is not well written IMO and has a forever loop waiting on the BUSY pin instead of implementing a timeout like the GxEPD2_PP library does.

Where in the code do you specify the DC, RST and BUSY pins?

I noticed also in your code that you disable an "LDO". What does this LDO power?

[friedl_1977]

Hi @Peekay -

I am going to try it for sure, just under some pressure to get some prototype boards out tomorrow but will send the rest of the weekend testing that.

LDO is pin for controlling the linear regulator providing the power for the GSM modem. I have left it on as well, there is not change in the outcome.

Regards
Friedl.

[friedl_1977]

I am still on this screen issue.... driving me nuts

I have found a workaround, not as smart as it sounds, simply keeping the modem connected and then forcing a restart when the screen needs to update. This does present another problem.

Long Story short, I need to be able to keep a GPIO pin HIGH during restart. Is this even possible?

The GPIO pin latches the Battery disconnect function of the LiPO charger, so pulling it HIGH with hardware is not an option as I need to be able to actually set (and keep) it LOW as well.

Regards,
Friedl,

[friedl_1977]

EDIT: SOVED (sort-of)

@peekay123 @chipmc

Ok.... as last ditch effort this morning I turned off Threads... lo and behold it works!!! I am not sure why, hope someone can shed some light, but for now I am going with this option.

Another possible solution was to try Hibernate or Sleep modes and see whether one of them can resolve the issue.

Regards, Friedl.

[peekay123]

@friedl_1977, I can't figure out what the problem might be and why turrning off threading would fix it. I don't have a Waveshare display to test with though I do have a BSOM B404x dev board to test with. I may try and fiind an e-paper display to test with though the dev board likely doesn't behave the same way as your custom PCB. Might be worth a try nonetheless.

[friedl_1977]

Hi @peekay123 -

I will run some more tests this evening to make sure it is stable and I get continued reconnects without any problems.

Please do not go out go your way to test, but it would be nice to know why this is happening. I testing this using Particle Dev board and a Waveshare screen on a board to eliminate any issues on my custom PCB. The same problems persisted.

If you do find the solution, please let me know Maybe someone at Particle can also investigate.

Regards,
Friedl.

[peekay123]

@friedl_1977, did you try the GxEPD2 library? Are you using the epd4in2b_V2 Arduino library files from Waveshare. Besides being poorly written (e.g. no timeouts), I noticed that it assumes an dedicated SPI port and minimal RAM like on the UNO. One of the oddities is that the code uses a single SPI.beginTransaction(SPISettings(2000000, MSBFIRST, SPI_MODE0)); when the display is initialized but there is never an SPI.endTransaction() used. I wonder if this is causing issues. The GxEPD2 library is more robust and makes proper use of SPI transactions.

[friedl_1977]

Hi @peekay123

@peekay123

did you try the GxEPD2 library?

I started implementing it... but seems there are quite a few dependancies. I kept adding, but workbench kept giving me 'squiggles' so I thought I just try the other one again. I will probably revert to the GxEPD2 one later, but for now I am a little pressed for time.

@peekay123

I wonder if this is causing issues.

Not sure if this helps, but I tried adding SPI.end() in several places, including adding it to the sleep function in the library, but it had no effect. Based on my findings, the problem most certainly starts as soon as the screen has been initialized.

@peekay123

Are you using the epd4in2b_V2 Arduino library files from Waveshare

Yes, that is the one I am using. Another thing that does not seem to work is their calculation of the buffer size. According to them, the budder is calculated by the following formula: BufferSize = (width x height) / 8.

Based on this, the full size of the display will require a buffer size of 15 000. Instead, I have to increase this to at least 50 000 to avoid any SOS status on the B524. Unless I am missing something. Maybe another testament of a "not so greatly" written library

One more thing worth noting - They also mention that after calling epd.sleep(), you have to re-initialize the screen in order to wake and update it again. This is not my experience. Regardless of calling epd.sleep() or not, I was able to simply update the screen again without re-initializing it. To me this indicated the display is maybe never put to sleep ?? This was a while back when I was still initializing the screen during setup() but I am fairly sure this was the case.

I will definitely look into the other library again, I just need to get the product to the client as soon as possible. This display has been causing many delays

[friedl_1977]

Hi -

Maybe something to take note of for anyone looking to use these panels with their libraries. Attached is official feedback from WaveShare (after 2 months of trying to resolve this issue).

Whether it makes sense I suppose is debatable.

Regards,
Friedl.

[peekay123]

@friedl_1977

@friedl_1977

Based on this, the full size of the display will require a buffer size of 15 000.

The three-color unit actually needs two buffers. One for red/white and another for black/white. Basically the white is the default "background" color. So you should only need 30KB of display buffer space. Not sure why you need 50KB to avoid an SOS but it goes to show the poor quality of the library.

As for the sleep, again, I don't trust this library. I am on the cusp of buying one of these displays from Amazon to get it to work with the GxEPD2 library.

[friedl_1977]

Hi @peekay123 -

@peekay123

Not sure why you need 50KB to avoid an SOS but it goes to show the poor quality of the library.

I wish I was better a programming, hehe. I just followed their example sketch which as far as I know, only had the one buffer. I followed their formula and then started increasing the buffer until SOS stopped.

I still need to figure out how to display a QR code on the screen which will update twice daily.

@peekay123

As for the sleep, again, I don't trust this library.

Aside from the the fact that they do not use a lot of power, I cannot see myself using these in the future. They are extremely slow as well and also do not support partial updates (according to WaveShare support).

@peekay123

I am on the cusp of buying one of these displays from Amazon to get it to work with the GxEPD2 library.

I would be very interested in your results

Regards
Friedl.

[peekay123]

@friedl_1977, color e-paper is slower than monochrome ones and I just noticed that the Waveshare does NOT do partial refresh as you indicated. As such, I won't be buying one for that reason. So, some questions:

• What size display do you need (width, height or diagonal)?
• What pixel resolution?
• Is color required or is monochrome ok?

I will soon be working on QR Code display that works on a 2.7" Sharp Memory display. It's a very low power monochrome (400x240) display that I have a bunch of. I got a deal on a bunch of them some time ago and I am using them up.

I also played/used ST7302 based 250x122 display modules which are very fast and VERY low power. However, the resolution may not be high enough for large QR codes.