Help opening/closing GPIO pin after nerves crashes

steveryan

Hello,

I’m getting started developing with Nerves and Circuits.GPIO.

When my program starts I’m calling a function like below, to open GPIO pin 26 for output:

@output_pin Application.compile_env(:Program, :output_pin, 26)

  def setup_gpio() do
    {:ok, output_pin} = GPIO.open(@output_pin, :output)
  end

This has so far worked fine, but when testing something, I crashed the program, and now when I go to re-run it I get the following error:

(MatchError) no match of right hand side value: {:error, :already_open}

Which I take to mean, since the program crashed, it didn’t clean up GPIO pin connection, so it’s still left open. My question is, how do I now do anything with that pin. I have tried closing it, but since I do not have access to the handle I can’t get it to close. (e.g. GPIO.close("GPIO26") gives me an error.

Is there any way, short of unplugging the raspberry pi and plugging it back in that I can either get the handle of this GPIO connection so I can write to it, OR close the connection, so that I can reopen it and capture the handle?

6 comments

/nerves #circuits_gpio

0 351 6

2024-09-16 14:49:27 UTC

Showing Posts 1 to 6

Show Best Posts
Show All (oldest first)
Show All (newest first)

lawik

Nerves Core Team

I have dealt with this at times by implementing the terminate callback (a GenServer owned the reference) and making sure it tidies up before it dies.

I would assume restarting the BEAM would help..

Post #1

Hermanverschooten

Lars, maybe a liitle bit of code to help out?

Post #2

jjcarstens

Nerves Core Team

Do you have reproducible code? Typically closed process reference is cleaned up by Circuits. The fact you’re getting that error tells me you may not be opening the GPIO from the same process(es) that crashes, you may be inadvertently trying to open it multiple times on process boot, or a potential bug in Circuits. But I’ll need a little bit more code example to be helpful in figuring that out

Post #3

fhunleth

Co-author of Nerves

@jjcarstens A few people have had similar problems when Circuits.GPIO started requiring that there only be one reference per GPIO at a time. I think that Circuits.GPIO will need to be more helpful since it is turning out to affect more people than expected.

In case it’s helps, the happy path for using Circuits.GPIO is to wrap a GPIO or set of GPIOs in a GenServer. The GPIO reference returned by Circuits.GPIO.open/3 should only exist in that GenServer’s state. I.e., don’t return it. (This is what @jjcarstens and @lawik said, but it seemed good to repeat.) When the GenServer crashes, Erlang’s garbage collector will clean up the GPIO reference and that will free up the GPIO to be used when the Supervisor starts it up again. Adding a call to Circuits.GPIO.close/1 in the terminate callback like @lawik says seems nice. Erlang’s garbage collector is normally amazingly quick at cleaning dead processes up should terminate not get called.

The current unhappy path for working with GPIOs is to create an API that returns raw references. This seems like a completely reasonable thing to do, but once the GPIO references get stored in a couple processes, Erlang’s GC will probably think the GPIO is alive when it’s really not.

If the code isn’t performance critical, try using Circuits.GPIO.write_one/3 and Circuits.GPIO.read_one/2 to avoid processes owning references completely. This might be a quick fix.

I filed an issue on Circuits.GPIO since it should be possible to do something without rebooting.

Post #4

steveryan

Really appreciate all the responses, and especially the issue in the Circuits.GPIO.

Some additional information that might help:

While I’m still prototyping my design, I’m doing this all in a live book running on the raspberry pi itself rather than running my program directly with Nerves on the board. That could potentially be impacting it I guess.
I have not wrapped this in a GenServer, you are correct. The original function I posted is called once when the program starts, the reference is saved to a variable, and I pass that variable around for the rest of the programs run.
The issue occurred when a simple, dumb mistake caused the program to crash (I think I called Float.parse on something it couldn’t understand or something). Then when I clicked “re-evaluate” it would crash at the setup_gpio function call because the GPIO was already open.

Post #5

fhunleth

Co-author of Nerves

Thanks for the additional detail about using Livebook. I totally see how you ran into this, and everything you did seems completely reasonable. At the moment, I’m unsure how best to fix this, but it’s pretty clear that something is needed.

Post #6

— All posts loaded —