gpioTerminate and interrupt callbacks about pigpio HOT 15 CLOSED

@Willjobs94 I just tried out the sample code with three LEDs and everything functioned as expected. The following line was removed from the sample code as socket is not defined:

socket.emit('setRGB', parsedRGB);

The output of several test runs can be seen below. During some test runs ctrl-c was hit to see if it had any effect, but it didn't. Everything still functioned correctly in subsequent test runs.

root@raspberrypi:/home/pi/pigpio# node test.js 
rgb TEst
creating rgb object
setting color
root@raspberrypi:/home/pi/pigpio# node test.js 
rgb TEst
creating rgb object
setting color
root@raspberrypi:/home/pi/pigpio# node test.js 
rgb TEst
creating rgb object
setting color
root@raspberrypi:/home/pi/pigpio# node test.js 
rgb TEst
creating rgb object
setting color
root@raspberrypi:/home/pi/pigpio# node test.js 
rgb TEst
creating rgb object
setting color
root@raspberrypi:/home/pi/pigpio# node test.js 
rgb TEst
creating rgb object
setting color
^C2016-03-30 18:07:09 sigHandler: Unhandled signal 2, terminating

root@raspberrypi:/home/pi/pigpio# node test.js 
rgb TEst
creating rgb object
setting color
root@raspberrypi:/home/pi/pigpio# node test.js 
rgb TEst
creating rgb object
setting color
^C2016-03-30 18:07:25 sigHandler: Unhandled signal 2, terminating

root@raspberrypi:/home/pi/pigpio# node test.js 
rgb TEst
creating rgb object
setting color
root@raspberrypi:/home/pi/pigpio# node test.js 
rgb TEst
creating rgb object
setting color
^C2016-03-30 18:07:36 sigHandler: Unhandled signal 2, terminating

root@raspberrypi:/home/pi/pigpio# node test.js 
rgb TEst
creating rgb object
setting color
root@raspberrypi:/home/pi/pigpio# node test.js 
rgb TEst
creating rgb object
setting color
root@raspberrypi:/home/pi/pigpio# 

Above you mention the following:

when I stop my scripts and run it again, I loose gpio control until I reboot the system

What exactly does this mean?

Is it the case that the program runs successfully exactly once and then never again?

Additional questions:

• What version of the pigpio C library is being used (grep PIGPIO_VERSION /usr/local/include/pigpio.h)?
• What version of the pigpio Node.js package is being used?
• What version of Node.js is being used?
• What version of Rasobian is being used?

from pigpio.

If you change the sleep 1 to sleep 10 it will execute 100's of times without error (at least on my early PiB and my current Pi2B).

I don't understand why the sleep makes a difference.

I have to assume the ISR 200 ms timeout happens during the execution of gpioTerminate. Quite why it has the effect it does I do not understand.

Let me think about this for a while.

from pigpio.

Leaving aside quite what is happening I'll add the following code at the start of initReleaseResources in pigpio.c.

   /* shut down running threads */

   for (i=0; i<=PI_MAX_USER_GPIO; i++)
   {
      if (gpioISR[i].pth)
      {
         /* destroy thread, unexport GPIO */

         gpioSetISRFunc(i, 0, 0, NULL);
      }
   }

At some stage I'll revisit the whole area of library termination. I have not done a repeated cycle test for a year or so.

from pigpio.

I changed the sleep 1 to sleep 10 and tried it a few times but still got the error each time. My system is very likely to be configured differently to yours however:

pi@raspberrypi ~/dev/pigpioc $ uname -a
Linux raspberrypi 3.18.11-v7+ #781 SMP PREEMPT Tue Apr 21 18:07:59 BST 2015 armv7l GNU/Linux

pi@raspberrypi ~/dev/pigpioc $ gcc --version
gcc (Raspbian 4.8.2-21~rpi3rpi1) 4.8.2
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

pi@raspberrypi ~/dev/pigpioc $ cat /etc/issue
Raspbian GNU/Linux 7 \n \l

If you change the sleep 1 to sleep 10 and change the ISR 200 ms timeout to an ISR 1 ms timeout I'd imagine that the error will occur more frequently again.

from pigpio.

Yes, adding code to destroy the threads and unexport the GPIOs is a good idea.

from pigpio.

I'm not sure about unexporting the GPIO. If people want the GPIOs unexported they should really shut the ISR down themselves. I don't like double guessing a user's intentions. In this case it is simpler to clear the ISR down which as a consequence kills the thread (which I ought to do) and unexports the GPIO (which I probably should not do).

from pigpio.

You're probably right and your proposed solution is fine for me. When opening this issue I somehow assumed that the initMboxBlock: init mbox zaps failed error was going to occur a lot, perhaps even always. In reality, I had no idea why the error was occurring but regarded the required reboot as being quite dramatic, especially if it was often required. I now think that it will only happen if the interrupt callback is called while gpioTerminate is executing. I'm not familiar with the internals of pigpio but would imagine that two threads are working with the same resource currently and that this is what causes the error. As you mentioned above, library termination is something that you'll look into at some stage.

Below is a variant of the same test program with sleep 1 and an ISR timeout of 150 ms. The ISR will timeout at 900 ms and would timeout at 1050 ms if the sleep was for longer. The important thing is that it doesn't timeout together with the sleep 1. I've ran it over 1000 times without error.

#include <unistd.h>
#include <stdio.h>
#include <pigpio.h>

#define GPIO 4

void isr(int gpio, int level, uint32_t tick) {
  printf("isr - gpio: %d, level: %d\n", gpio, level);
}

int main(int argc, char *argv[]) {
  int version;

  if ((version = gpioInitialise()) < 0) {
    return -1;
  }

  printf("version: %d\n", version);

  if (gpioSetISRFunc(GPIO, EITHER_EDGE, 150, isr) != 0) {
    return -1;
  }

  sleep(1);

  gpioTerminate();
}

from pigpio.

Proposed fix added to V40.

from pigpio.

Thanks you very much. I just gave this a try and everything is looking good now.
I see that you also decided to unexport the GPIO :)

from pigpio.

Unexporting the GPIO required no effort on my part. I'd have had to write some special code not to unexport when killing the ISRs. In other words I couldn't be bothered!

from pigpio.

I'm having this problem, when I stop my scripts and run it again, I loose gpio control until I reboot the system. I'm using the pigpio nodes package for PWM manipulation

from pigpio.

@Willjobs94 I'm not sure if you're having the exact same problem as the pigpio Node.js package doesn't actually call the gpioTerminate C library function (which may be an issue in itself). Do you have a sample program in JavaScript (or C) for reproducing the problem?

from pigpio.

Well @fivdi this is what I do,

RGB constructor
RGB Test

from pigpio.

I've tested now and work as expected but I was having that issue before, maybe was something on my hardware that I miss, cause now I tested with a cleaner circuit than before.

Thanks for the fast help and feedback.

from pigpio.

Excellent, that's good news :)

from pigpio.