Enabled system threading, GPIO starts acting up

Troubleshooting
1

Hello!

I been running a single thread application up until now when my device needs to be responsive going between areas that have coverage and areas that don’t, which with a single thread causes the device to lock up while reconnect attempts (becoming unresponsive).

Now I’ve been switching over to multithreading by SYSTEM_THREAD(ENABLE), but all of a sudden the two tactile buttons I have connected to B0 and B2 pin are showing some strange behavior. What I want to accomplish (which I do when multithreading is disabled) is to increase and decrease a counter using these two buttons. Pushing a button should increase/decrease two integers (in total three) as below:

volatile int current = 0;
volatile int inc = 0;
volatile int dec = 0;

And triggered by

if (digitalRead(incButton)){
    inc++;
    current++;
    printDisplay();
    while(digitalRead(incButton)) {}; // Wait for release
}

if (digitalRead(decButton)){
    if(current>0){
        dec++;
        current--;
        printDisplay();
    }
    while(digitalRead(decButton)) {}; // Wait for release
}

What happens running this code is that three integers randomly jump up and down, as if the buttons were pressed. Connecting a multimeter to the selected pins does not show any fluctuation in current when the integers change. What I’ve noticed though is that only manipulating ONE integer inside the if statement doesn’t cause these random jumps, like below:

if (digitalRead(incButton)){
    //inc++;
    current++;
    printDisplay();
    while(digitalRead(incButton)) {}; // Wait for release
}

if (digitalRead(decButton)){
    if(current>0){
        //dec++;
        current--;
        printDisplay();
    }
    while(digitalRead(decButton)) {}; // Wait for release
}

I’ve been struggling to fix this, but can’t find any solution. Can someone explain to me what’s going on here? The reason for not only doing a substraction between the inc and dec is that the integer “current” can be manipulated from the server side as well and needs to be stand alone.

Thanks!

2

Just for the purpose of testing, I removed the “current” ++/-- from inside the if statements, and made a simple subtraction between the two integers (inc and dec) to calculate the “current” integer. With this change, the integers still randomly jumps! I really can’t get my head around this…

Edit:
New observation! Whenever the Electron does something on the system thread, e.g. goes from offline to online (for example when booting up and the Particle.connect() is callled), the integers are changing! And in such fashion that if I trigger incButton while status LED is rapidly flashing cyan or flashing green, whenever connection is established it “recalls” a couple of these interactions, subtracting some of the button interactions made (resulting in a few decrements).

Edit2: Real problem detected
OK I have now circled the problem down to that whenever a change in being made in the application thread (e.g. button being pushed, integer manipulated) while the system thread is also running (e.g. Particle.connect or Particle.publish), the application thread acts up.

So if I would increase the counter by one but pushing the incButton whilst the Electron is connecting, I would get an additional 1-4 clicks on either incButton or decButton.

So since I’ve managed to pinpoint the problem I’ll make another thread with a more accurate topic and post. Will link the new thread once created.

1 Like
3

@ftideman, one primary issue is that you don’t debounce your buttons. You can do a search on the forum for “debouncing” or you can take a look at the clickButton or debounce libraries on Particle Build. Once you’ve added debounce, you can reassess any issues possibly caused by threading.

4

@peekay123 Is it really debouncing that causing the problem? Since if I press for instance incButton while the system thread is running, both incButton AND decButton will fire. I made short video of the phenomenon here: https://www.youtube.com/watch?v=0daN_WO9Xxg

If I would disconnect the B2 pin (decButton) however, the dec integer will not fire as it did in the video.

5

@ftideman, are buttons being sample in loop()? If so, I’m not sure why you declared your variables as volatile. Such a declaration would make sense if they were sampled in an interrupt but not is the code is entirely run in loop().

Button bounce can be weird. However, just to be sure, have you tried the buttons on other pins like D2 and D3 for example?

1 Like
6

@peekay123 Just quickly tried the debounce library in Particle Build, and hopefully not speaking too soon - it looks like it did the trick!! I’ll probably switch to the clickButton library though :slight_smile: I really feel this issue is way over my head, don’t really get why a debounce would cause this issue but nevertheless, if it works, it works! :smiley: Big thanks!!

Regarding other pins: yes I tried most of them, same issue.

Regarding volatile: I was desperate and tried many things. Have obviously not fully understood what volatile actually means :slight_smile:

The moral of this thread: Kids, always debounce your buttons!

1 Like
7

Despite your problem seems solved, did you have pull-resistors (internal or external) attached to your button pins?

8

@ScruffRf, the debounce libraries take care of that. :wink:

9

@peekay123, I do know, but the OP wrote

And the missing pull-resistors might be a comprehensible reason :sunglasses:

1 Like
10

@ScruffR I used software pulldowns and while trying to fix the problem also tried external 1M ohm pulldowns on my buttons, didn’t work for me though.

Thanks for helping me out so far :slight_smile: Now when the buttons are working as they suppose to, a new little problem arose. When the Electron is either online or offline, I can push the buttons in a high frequency and all clicks get registered. However when the Electron just waking up from sleep (or just rebooted), flashing white or green, and you push buttons with high frequency (>~1.5 per second) only every second or so click gets registered. I have the feeling that the application code “slows down” during the time when the system code is running. Does it work like that? If yes, is there a way around this? Also, when you do push the buttons repeatedly when either cellular is turning on or connection to the cloud establishes, two different scenarios can occur:

  • Electron successfully connects to the cloud, led starts breathing cyan, and the application code runs in a fast pace again meaning that every button click is registered, OR

  • Electron starts breathing cyan, but is NOT connected to the cloud, and the application code “runs slow” until you manually reboot the Electron

Do you have any idea what may cause this? Maybe @peekay123 ? I’m running SEMI_AUTOMATIC mode btw.

Edit: I just saw in the “mode-switching” section that in MANUAL mode, not calling particle.process frequently enough can cause “… erratic behavior, such as: The Electron breathing cyan when in fact it is not connected”. Will try to implement manual mode to see if that’s a possible fix, but meanwhile if you guys have any other ideas or suggestions, shoot them at me. :slight_smile:

11

Never mind, I fixed it! :smile:

Because my OLED was glitching (skewed graphics) when you tried to update the screen while the system thread was running, I tried implementing a block of screen updates when that happened. But it obviously didn’t work out the way I though and caused this weird behavior… So I removed that “feature” and now the buttons are responsive no matter the connection state! I still have the screen glitch though, which I will dig into now… :slight_smile:

12

@ftideman, glad to hear! You could start another thread on the screen glitch if you need assistance. :wink:

1 Like