LowPowerLab Forum

If I leave my MightyHat/Pi unplugged for a few minutes, my Mote doesn't retain its sketch and needs to be reflashed.
Ideas?

Here is a video.  Thirty second outage and the Mote loses its image.

https://youtu.be/NO5uJURT1bE

1) Are you running the default sketch? Any special mods to that?

2) How do you power the whole setup?
Is it my impression or do I see 2 USB connectors (one to MHat, one to Pi)?

Anyway, unplugging power with no battery attached - everything powers down, as expected, regardless if it's 1 second or 30.
When you reapply power, MHat becomes active, then you can start powering the Pi again etc.

3) You specifically mention 30 seconds  and you count it out loud in the video - is that because this does not happen for less time?

x) you then proceed to attaching FTDI - this is sort of OK - if the Pi is OFF (no interference from Pi's serial) and the GROUNDs are the same.

Total default sketch except for network ID.

That is a USB power cable into the Hat.   The other cable is an HDMI cable out to a display.

I'd expect everything to power down when power is turned off, but wasn't expecting the sketch to get erased.

The sketch stayed put for a 5-sec power loss, lost for a 30-sec loss.  Didn't test the delays in between.

I'll be more careful about only one ground.

The sketch being erased - that I could hardly believe until I read the atmega flash with an ISP programmer, and compare.
Or something very wrong is going on, nobody ever reported anything like this.
I don't know what to guesstimate could be happening next...

Can you try this without the Pi (just the MHat)?

Hmmm.

At the point I "thought" it needed a reflash, just a reset fixed it.  Pretty reliable behavior.

I'll try it standalone and see if maybe the HDMI or something else might be impacting it.

Tested with the Pi/Hat isolated with just a single power port connection.

Same behavior.  Needs a reset button press to get it to come alive.

I'll try just the Hat alone...

Even just the Hat standalone exhibits the same behavior.  Requires a reset button press after powering up.

I'll need to find a fix for this since it will need to recover well after a power cycle as this unit will be remote without user access.

Ok let's keep the conversation open as you make any progress.
I have to find some time to test a MHat for this behavior, and if it's a fault, it has to be fixed.

BTW - will you not use a battery with this MHat?
That would keep it going, until the battery lasts (low battery shutdown), or power comes back. That's the only way I've been using (and intended) the Mhat.
Either way it should come back and run the code after a power fail.

I have been using it primarily just for the Mot/LCD/Power interfaces to the Pi.

I have a spare LiPo that I can use though.  That would be a quick fix. Good idea.

I have an older Hat on my 433 system that I don't think behaved in the same manner.  Could be a an edge case with the power-up cycle that causes it to not boot properly.

I will investigate on my end. Let me know if you find anything else.

Is there any way for me to reset the Moteino on the MH remotely from the Pi?

While the battery helps with short term power outages, being a remote system, I want to think ahead to how I can reset the Mot on the MH remotely if the battery ever runs down.

I'll look at the schematic and see if there is any way for me to tie a GPIO pin to the reset.

Yup you can do that easily through Pi pin 22, there is a solder jumper above the Pi header on the MightyHat.

Nice, thanks.

(https://i.imgur.com/HYGjH5D.png)

Has anyone else ever seen the behavior shown in the video above where you need to reset the Mote after a power-up?

I was just starting to analyze this exact issue. R3 - Pi3 - standard Sketch. Either the reset switch, or flipping the battery switch off/on again w/o battery attached will cause the reboot and then the LCD to print data. However, the sketch is still running on initial cold-boot, even without anything on the LCD (Backlight works, but the output is missing.)

I imagine is is with the sketch itself, and that will be the first thing I tinker with to find out what is happening.

Did some more debugging.
1) It is not the sketch, I tried changing the sketch as  as well as simply writing to the LCD without the U8G library.
2) I tried a fake 'reset', by jumping to program position zero, as well as invoking a watchdog restart. Neither worked.
3) The LCD seems to require a hard reset in order to start functioning.


For now, I will either run without LCD, or incorporate a PI reset of the MOTE if I need the LCD.

import RPi.GPIO as GPIO
import time

time.sleep(2)
GPIO.setmode(GPIO.BOARD)

GPIO.setup(22, GPIO.OUT)

GPIO.output(22, True)
time.sleep(2)
GPIO.output(22,False)
time.sleep(2)
GPIO.output(22, True)


FYI - I just added SPI_transactions to the RFM69 library, can you please backup your local RFM69 lib, get this latest version, and try again, see if it makes a difference?
This was due to a reported issue: https://github.com/LowPowerLab/RFM69/issues/114

I dropped in the new lib and recompiled/uploaded but I'm still seeing the same behavior. 

Felix, this is not a code - related issue, AFAIK. Here is the code I ran for one test, which didn't use any libraries.

Henry - Is it just the LCD that isn't working, or the entire sketch? For me it is just the LCD until RST. I want to make sure we are both experiencing the same issue and not confusing two similar but different issues.


#define CE  A1 //
#define DC  A0//
#define DIN  MOSI //
#define CLK  SCK //
void LcdWriteCmd(byte cmd)
{
  digitalWrite(DC, LOW); //DC pin is low for commands
  digitalWrite(CE, LOW);
  shiftOut(DIN, CLK, MSBFIRST, cmd); //transmit serial data
  digitalWrite(CE, HIGH);
}
void setup()
{
  pinMode(CE, OUTPUT);
  pinMode(DC, OUTPUT);
  pinMode(DIN, OUTPUT);
  pinMode(CLK, OUTPUT);

  LcdWriteCmd(0x21);  // LCD extended commands
  LcdWriteCmd(0xB8);  // set LCD Vop (contrast)
  LcdWriteCmd(0x04);  // set temp coefficent
  LcdWriteCmd(0x14);  // LCD bias mode 1:40
  LcdWriteCmd(0x20);  // LCD basic commands
  LcdWriteCmd(0x09);  // LCD all segments on
}

void loop()
{
}

It does seem like my MH Sketch is running despite the screen being blanked out.

Comforting to know the sketch is at least running in case it is intended to be used in a remote location.

Pulled out a beer an my oscilloscope in order to close the loop on this. 

Looks like, as expected, no RST signal is sent to the LCD on initial boot after power loss. However, since the RST button, PIPIN22, and the RES on the LCD are tied together, this does indeed drop the pin to ground when pressed. This is important as the LCD requires a RST signal in order to initialize properly. Before this is received, it is in an uninitialized state, so only the LED back-light works, since that is a separate function all-together.

Per the datasheet:
"8.1 Initialization
Immediately following power-on, the contents of all internal registers and of the RAM are undefined. A RES pulse must be applied. Attention should be paid to the possibility that the device may be
damaged if not properly reset."

I am not too worried about the warning.damage portion, as I am mostly using this to debug/test.

I see two possible fixes:
1) HW redesign in V4
2) Might be able to at least alleviate the issue with a PI-based reset on powerup. As long as it is sure it is a fresh boot (maybe uptime is a decently high number...), PI will send a RST signal itself. Obviously, more design considerations in this one, but I think I will goo down this route, if I choose to do anything at all.