PCD8544 display behaves differently with saved()'ed code

I have some simple temperature display code which is giving me grief when I save() it to the Espruino. The code continues to run after a reset or power cycle but the characters are barely visible on the screen. It's like the contrast is turned down to almost zero. It works and displays fine when the same code is just uploaded and run directly. I've read all the threads about using onInit() but it's not helping at all.

Any ideas? Code looks identical in both cases using dump() apart from the contents of g.buffer;

Thanks

var g;
var rtc;
var numReadings = 10;
var temperatures = [];
var index;                  // the index of the current reading
var total;                  // the running total
var average;                // the average

function onInit() {
  index = 0;                  // the index of the current reading
  total = 0;                  // the running total
  average = 0; 
  SPI1.setup({ baud: 1000000, sck:B3, mosi:B5 });
  clearInterval();

  // initialize all the readings to 0:
  for (i = 0; i < numReadings; i++){
    temperatures[i] = 0;
  }

  digitalWrite(B13,0);
  I2C2.setup({scl:B10,sda:B11});
  rtc = require("DS3231").connect(I2C2);
//  setInterval(function() {
//    console.log(rtc.readDateTime());
//  }, 1000);

  g = require("PCD8544").connect(SPI1,B6,B7,B8­, function() {
    g.clear();
    g.setContrast(0.45);
    g.flip(); // copy this to the screen
    setInterval(onTimer, 1000);
  });
}

function onTimer() {

  // subtract the last reading:
  total = total - temperatures[index];

  var val = analogRead(C0);
  temperatures[index] = (((val*3.3)-1.25)/0.005);

  //console.log("Total: " + total);
  //console.log("Temperature: " + temperatures[index]);

  // add the reading to the total:
  total = total + temperatures[index];

  // advance to the next position in the array:
  index = index + 1;

  // if we're at the end of the array...
  if (index >= numReadings){
    // ...wrap around to the beginning:
    index = 0;
  }

  // calculate the average:
  average = total / numReadings;

  //console.log("Average: " + average);

  g.clear();
  g.setContrast(0.45);
  g.setFontBitmap(); // simple 8x8 font
  g.setFontVector(20); // large font
  g.drawString(average.toFixed(2), 0, 0);
  g.drawString("C", 65, 0);
  g.setFontVector(15); // large font
  var localtime = rtc.readDateTime().split(" ")[1];
  g.drawString(localtime, 0, 32);
  g.flip(); // copy this to the screen
}

onInit();

I'm guessing it's some sort of timing issue. If I add

 var g = require("PCD8544").connect(SPI1,B6,B7,B8­, function() {

into the timer function, so that it's called every time, it works ok but flashes the screen on every update.

Two things I'd try:

1) Maybe the PCD is booting up slower than the Espruino, and on startup, the Espruino is trying to talk to it before it's ready? This sounds familiar to me. Try putting the connect call in a timeout, ie:

setTimeout(function() {
    g = require("PCD8544").connect(SPI1,B6,B7,B8­, function() {
        g.clear();
        g.setContrast(0.45);
        g.flip(); // copy this to the screen
        setInterval(onTimer, 1000);
  });},2000);

2) Remove the onInit(); on the last line. When you send the code, kick off onInit() manually for testing, or do save(); if ready to save it. I don't think this is the issue in your case, but as things get more complicated, it becomes increasingly likely that saving after onInit() will run differently than saving before onInit();

That makes a lot of sense. Thanks. I'll try as soon I collect the turkey :-)

I wondered about the OnInit(). It's in most of the examples I saw but I wondered if it was auto-called. I'll comment it out again.

As @DrAzzy says, it could be to do with the initialisation of the display - I see you're setting pin B13 up - is that somehow connected to the display?

There's also an issue with the 1v71 firmware (I've fixed this in current builds but haven't yet released an 'official' firmware) that means that right after power on, timeouts that are created from onInit (or something called from it, like the display driver) may not be the correct length. You could try adding setTime(getTime()) at the top of onInit and see if that helps?

Thanks Gordon. @DrAzzy's delay did the trick. The B13 was supposed to turn on the backlight but it's better with it off. I didn't see any difference with adding setTime(getTime()) tho. I'm on 1v71.

@Gordon, what should setTime(getTime()) do?
Because when I add this lines it starting to behave as I expect, but only until power is disconnected. After that, the the only way I could revive my Espruino(1.3) is to reflash it. I'm using v72.

You shouldn't need setTime(getTime()) with v72 builds (and as @conor reported, it didn't fix the problem anyway) - Maybe Gordon can answer why it's soft-bricking your Espruino, but now that v72 is out, it shouldn't be necessary at all.

Did you try the delay method I suggested, and that worked for conor? When you power-cycle the PCD8544+Espruino, you need to give the PCD8544 a second for it's controller to boot before you can write to it.

@DrAzzy, solution with delay helped a lot. Actually, only with it I was able to move forward. So, big thanks here.

But, still, it's interesting why adding this line still(!) help. And why it stops working after hard(power) reset. With setTime it will properly restart after RST, w/o it - doesn't.

Maybe I'm just doing something very wrong? :)

Well, actually I'm stuck exactly at the where topicstarter did. While connected to USB screen behaves as expected. But when I switch to battery - I barely can see what is written on my screen.
I increased initial timeout to 5 seconds, but it didn't help.
Espruino is working, according to LED indication, but screen - doesn't.

In the end cleaned up my code, reflashed Espruino numerous times and at some point it started working. For me, it seems that "saved state" was causing some of my problems.
With my Arduino background I sometimes get not what I expected. Is it possible to load to Espruino exact copy of what I wrote, w/o any "artifacts" whatever origin they might be?

So on battery, you can see the words on the screen, they're just too light?

That makes a lot of sense - it's likely getting a lower voltage when running from battery, hence the image is lighter. Increase the contrast with the setContrast() method until it looks good.

reset() will reset the state of Espruino (following that with save() will then save that blank state) Putting code in right hand side of IDE, and doing "send to Espruino" on default settings will reset() first.

Well. Now it's really weird :)

It seems that I have unstable result with just plug/unplug my "espruino with screen" to power. And sometimes I can see everything on my screen just perfectly, sometimes.. well.. nothing. And sometimes very-very light. I'll continue to investigate, but it seems that roots of this problem is somewhere with SPI and screen itself. And it's completely new field for me, first time playing with SPI and screen :)
And even delay with screen init, while quite obvious, didn't came to my mind :)

I can post my code, but it's very similar to the one that you can see on the top. The only difference I see is where SPI1.setup() located. Mine - outside of onInit().

If you could post all code you're using and exactly how wired, I can see if I can reproduce it.

You're using official board with v72 release firmware?

Wiring is almost the same as for "direct soldering screen to Espruino", except mine screen is powered from GND and 3.3. Espruino itself powered with step-up from U1V10F3 from Pololu (solar => supercapacitor => stepup). So, in theory, I have always 3.3 for Espruino and screen.

I'm using KS version(1.3?) with v72 firmware.

require("Font6x8").add(Graphics);

SPI1.setup({ baud: 2000000, sck:A5, mosi:A7 });

var interval = 10;

var g;
var time;
var voltage;

function onInit() {
  time = 0;
  
  
  setTimeout(
    function() {
      g = require("PCD8544").connect(SPI1,A6,B1,B0­, function() {

        //g.clear();
        //g.drawString("Init complete.", 0, 1);
        //g.flip();

        A4.write(1);
        A4.write(0);

        setInterval(onTimer, interval * 1000);
        //g.setContrast(0.5);
        g.setFont6x8();
      });
    },
    5000
  );

}

function onTimer() {
  voltage = analogRead(A3) * E.getAnalogVRef();
  time += interval;

  g.clear();
  g.drawString("Seconds: " + time, 0, 0);
  g.drawString("Volts: " + Math.round(voltage*100)/100, 0, 8);
  g.drawString("Reference: " + Math.round(E.getAnalogVRef()*100)/100, 0, 16);

  g.flip();
}

Where are you connecting your 3.3v supply to?

If you're connecting it to Espruino's power pins then it still goes through a 3.3v voltage regulator (which needs a bit more than 3.3v to work). If that's the case then Espruino+the display may only be getting ~3v or so, which may not be enough for the display?

About the setTime(getTime()) - are you using the main 1v72 release from the website/web IDE, or one of the github or BigRam builds? If it's not from the website and is more than a week old then it's quite possible it'll be an earlier build that doesn't have all the features/bugfixes of the main build?

@Gordon, power comes near A1 in through GND and 3.3 on the side. Screen is connected also near A1 at the BTN1(GND and 3.3). See attached image. This way it still goes through voltage regulator?

Until I have clear understanding how things works I usually try to avoid complications, so mine v72 came from Web IDE. Currently it's the simplest way to work with Espruino :)

1 Attachment

If you're bringing power in on 3.3v, you're bypassing the regulator entirely. I sure hope that power source is regulated 3.3v?

Yes, it's regulated with U1V10F3 module from Pololu.

That all looks good to me. Have you checked that the voltage does stay constant? You're not using setDeepSleep(1) in your code - which is fine, but the board could draw around 30mA without it - which may be running down your supercapacitor?

Maybe you could try adding some digitalPulse(LED1,1,10) commands for the 3 LEDs, to make sure that the board is running the code you expect. If the voltage from the Pololu board has increased slowly then the board might have 'browned out'.

One other thing to watch out for is that when you plug in USB, the voltage will then come in through Espruino's voltage regulator - hopefully the Pololu module won't mind having power on its output while it itself is unpowered?

Come to think of it, does the board run reliably while connected to USB?

@Gordon, deep sleep if for the future, when I have stable/predictable behaviour with screen.

My voltmeter shows constant 3.3V(+/- 0.02V). Between output of my "power module" and Espruino there is an electrolytic 1500uF capacitor. It's there for two reasons. First - remove possible pulsations from buck converter(step up module). Second - provide backup power storage for Espruino+screen startup. 1.5mF is a lot, but I currently doesn't have smaller :)

Approx 1 of 5 times when I connect Espruino to "power module", screen is working. And when I can see it's working it can last for about 1hr with fully charged supercap. I hope that with deep sleep it can be improved.

There is an
A4.write(1); // turn screen light on
to make sure code is running properly. Actually, I don't see any other points that I could check with LEDs.
I shall receive my mooshimeter soon, it should help to check if board is "browned out".

While board connected to USB everything is working properly.

Anyway, thanks for the help. I'll try to do some more investigations on my own and post my findings later.

So it always turns on the backlight (via A4?) even when the display isn't working?

Other thing you could try is to make sure the Reset pin isn't floating at power on (digitalWrite(B0,1) right at the top of onInit), which may confuse the display?

If it all works on USB I'd guess it's some kind of power supply issue though.

When you're running off the power supply, is it still unreliable starting up when you just press the RST button?

It is unreliable even on USB when I press RST. After RST I see backlight blink almost immediately, while it should be after few seconds. And screen is not starting up after RST. Only time when it was working properly with RST is when I used setTime(getTime()). But only until power is turned off.

I'll check for Reset pin.

Backlight is turned on only for a moment.

Actually I've just set this up myself and can get the same thing to happen. Sorry about that.

Looks like it is a software bug - not sure how that crept in, unless the fix didn't make it into 1v72 after all. It seems like it might be to do with the recent change which allows the real-time clock to keep track of time between resets.

It seems that if you completely power down Espruino so the RTC loses all of its state then it should work. However if you reset Espruino then its RTC remembers the last time and everything breaks.

Looks like just adding even setTime(0) is probably enough to fix it in 1v72, but I'll make sure I get this fixed properly for 1v73 (which it looks like I'll be releasing quite soon!).

Ok, I've fixed this now, so it'll be in 1v73, or any of the nightly/github builds after tonight.

There was also another bug that RTC appear to speed up and slow down every second or so, which is also fixed now.