Nextion display serial1 causing solid cyan

Hardware
1

Since upgrading to 2.01 I’ve been having multiple issues with my Photon and Nextion display. When I push a simple count-up sketch to the device I can demonstrate proper photon and nextion display functionality. When I then update the photon with the example sketch from the onewire library ((Particle Web IDE) with the nextion code commented out the device works fine, updating particle.variable and particle.publish values as expected. When I then update the photon with the sketch including the nextion section the photon doesn’t update the display and then locks up with a solid cyan led after about 30 sec. I tried updating the OS to 3.0.0-rc.1 with no change. Any ideas on how to fix this?

#include "DS18.h"

DS18 sensor(D4);
double tempF = 0;

void setup() {
  Serial.begin(9600);
  Particle.variable("temperature",tempF);

}

void loop() {

  if (sensor.read()) {
    tempF = sensor.fahrenheit();
    // Do something cool with the temperature
    //Serial.printf("Temperature %.2f C %.2f F ", sensor.celsius(), sensor.fahrenheit());
    Particle.publish("temperature", String(sensor.fahrenheit()), PRIVATE);
    
    String command = "page0.t0.txt=\""+String(tempF, 1)+"\"";  //takes the var tempF, converts it to a string and sends it to the display
    Serial1.print(command);
    Serial1.write(0xff);
    Serial1.write(0xff);
    Serial1.write(0xff);

    delay(10000);
  }

}
2

To start with, you are lacking a Serial1.begin() call in your code example.

As a rule of thumb I’d then replace the delay(10000) with a millis() delay like this

void loop() {
  static uint32_t msLastPublish = 0;
  if (millis() - msLastPublish < 10000 || !sensor.read()) return;
  msLastPublish = millis();
  ...
}

and also stay away of String and rather go with old-fashioned C-strings (aka char[]) and snprintf()

1 Like
3

Dang-it. One lousy character! I chased that for two days. Thanks ScruffR! Also, what is the thinking behind your comment about staying away from Strings?

4

String objects use dynamically allocated memory to store the content and when the string outgrows its original size it often needs to be moved to some other place which can leave a salvageable heap fragment behind which over time may cause your device to behave erroneously and is hard to debug.

Particularly concatenations and temporary objects can speed this up.

5

Hi @ScruffR, I am using String objects. Should I be able to see the memory usage incrementing over time in the vitals memory usage?

6

Nope, the single number of free memory won’t tell you how fragmented that memory is.

System.freeMemory() would report the same number whether you have one single block of 80KB or thousands of small blocks of a few dozen bytes.

You could check whether you can allocate a block of a given minimum size that is acceptable for your use case. When you can allocate it you may free it immediately again, but if that attempt fails you could log that fact and then reset the system to clear the heap again.

1 Like
7

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.