-
Notifications
You must be signed in to change notification settings - Fork 571
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GPIO input gives segmentation fault on BeagleBone Black in v3.1.0 #2313
Comments
Can you add the result of GpioController.QueryComponentInformation to the question? I don't remember any relevant changes there. |
3.0.0 (working)
3.1.0 (not working)
No surprises that this fixes the problem when running 3.1.0, but obviously the default for the BBB is not ideal.
|
At least there's a workaround ;-) I guess we have to analyze why a) 3.0.0 prefers sysfs over libgpiod and Can you verify whether libgpiod would work with 3.0? |
I hadn't thought to check that. |
[Triage] This somehow sounds like a problem in libgpiod itself. There's a command line tool called gpiod which you could use to check whether the bug is in the libgpiod library itself or in our code. Here's a link: First try to run |
gpiod seems to work fine on its own. My above example logical pin of 67 maps to gpiod chip2 pin3. The following works and gives a 0 or 1 depending on whether I connect the pin to GND or 3V3.
|
The gpiochip number is most probably the culprit. In fact, by default the libgpiod driver in this repository defaults to zero. Could you please try creating the libgpio driver passing Then you pass this instance to the If this still does not work, there may be a mismatch from the logical/physical pin number due to the Thanks |
This works - using gpiod and referring to the pin as gpiochip2 pin 3, rather than the pin 67 that worked when 3.0.0 defaulted to SysFsDriver:
As we ascertained earlier, this also works:
I suppose we can put this down to a change in the default driver from SysFsDriver to LibGpiodDriver and the fact that the pin numbering then has to be changed to match. Not great that previously working code breaks at runtime with nothing but a NuGet package update though. |
Great to hear that. The mismatch between physical and logical pins depends on the absence of a specific driver like this one: It may also be important to find a way to detect the board and pick the correct driver as it happens here: @pgrawehr Am I forgetting anything else? @FredMurphy Would you be interested in contributing to supporting the BeagleBone Black with a pull-request? Thanks |
|
That would be great! Thanks |
[Triage]: We are trying to figure out what is the root cause of the segfault. Is it because when we PInvoke we do it with a chip that is wrong? Or is it because we are not catching an error returned by that PInvoke and trying to use the handle with the invalid handle? @raffaeler or @pgrawehr will try this out in the following week. If the issue is the former, we'll have to investigate and see how to fix but we won't block the release for this. If the issue is the latter, then we will fix the catching the error before our next release. |
I'm happy to do some testing if nobody has a BeagleBone Black, I'm guessing that the changed default driver meant I was unwittingly trying to use the LibGpiodDriver with chip 0 and pin 67 |
That would be super helpful, yes. You should be able to create the Driver yourself |
From the previous messages I understand that @FredMurphy already successfully tested that. The only reason now to create a specific driver is to bake the pin mappings in it, which afaik requires talking to different gpio chips depending on the gpio being accessed. @FredMurphy Could you please confirm or correct my statements? |
Describe the bug
Opening a pin for input on a BeagleBone Black gives a Segmentation Fault in v3.1.0. The same code works in v3.0.0
Steps to reproduce
code compiled with the following and then copied over via SCP:
Expected behavior
An input pin should be opened and value can later be read.
Actual behavior
Segmentation fault as the pin is opened. Output pins work fine.
Versions used
dotnet version 8.0.204 (also tried 6.0.421)
BeagleBone Debian 11.7 minimal (although seems to happen on other versions too)
System.Device.Gpio version 3.1.0
Reverting System.Device.Gpio to 3.0.0. fixes the issue.
The text was updated successfully, but these errors were encountered: