Setup() not running immediately on Electron

Troubleshooting
1

Had a it of weird issue crop of while reorganising some of the code in my project (globals bloat). After finishing this I discovered setup() & loop() were not running until either the WLAN timeout or if I hit the reset button at which point the app would start flawlessly.
V0.7
SYSTEM_THREAD(ENABLED);
SYSTEM_MODE(AUTOMATIC);

Today trying to work our what I could possibly have done to confuse it, I took a copy of my (pre-restructure) codebase and removed libraries and functionality until it started to work again during which time the problem appeared to get worse (reset no longer fixing the issue). The results weren’t very illuminating (moved a const from a header file to the main program so I could leave the rest of it out and suddenly it was working), so I went back to the code I had restructured and compiled it afresh - behold the problem is gone.

This leaves me with (I think) 3 options,

  1. After discovering the problem I actually fixed it by mistake and then failed to flash that to the unit.
  2. Something was different about the compiler over the weekend and I encountered some kind of fringe bug.(certainly didn’t happen on a program that just flashed a light)
  3. Its possible my code is still faulty and any future small change like an extra flag etc before setup() could cause this to reoccur.

Given I can’t really post a project with multiple custom libraries and several 1000 lines of proprietary code to the forum, if it is a dodgy bit of coding does anyone have any idea what type of noob coding error could cause this kind of cooky behaviour. It just seems odd that the boring stuff we put before setup (globals variables and objects) could be enough to trigger the behaviour (the reset fix in particular), a stack/memory issue?

2

There are numerous possible reasons, but one thing is to note

Especially when you mention "objects" these aren't as boring as one might think.
When you create an object, the constructor will be executed, but since the order of execution in which constructors will be executed is non-deterministic you shallnot use any code in one constructor that would rely on any other constructor to have been executed already.

No idea if any of that applies to your project, but this could explain things.

2 Likes
3

Been a while, busy on other things. I like your thinking… so something like this before setup() could have been the root cause?

Box _box1(Inp1,Outp1,1);
Box _box2(Inp2,OutP2,2);
Pallet _Pallet(&_box1,&_box2,_Mode);
4

That’s possible but depends on what actually happens in the Box and Pallet constructors and potentially also what the respective parameters for these constructors are.
If these in turn are also objects passing them might also initiate implicit construction of temporary objects.

OOP is an odd beast at times :wink:

5

Hmm well the Box objects are literally what you might guess an input an output and an ID

Pallet was my attempt to be a little sneaky, constructor is:

Pallet::Pallet(Box *a,Box *b,int _Mode)
{
      palletMode = _Mode;
        pumps[0] = a;
        pumps[1] = b;

}

The idea being that rather than directly interact with Box1 & 2 I instead interact with the Pallet object and it will use the the Box sensor readings to act accordingly.

6

I see - in that case this could be a side effect of something I keep lamenting about in this issue mainly realted to SYSTEM_MODE(SEMI_AUTOMATIC) but might also strike here.

I can see Particle’s point of view, but I’m still convinced that the “new” behaviour is rather limiting and has more negative side effects for the user than the previous behaviour.

7

Whatever it is, it’s pretty weird, nothing resembling this behaviour happens with simpler programs it seems to pretty specific with whatever I’m doing before setup() and when I thought I had it licked it got worse.
I shall try removing this OO piece completely and see what happens.