GPIO API, rtems_semaphore_obtain fails
gedare at rtems.org
Sat Oct 31 13:43:51 UTC 2015
This looks like a bug. Enabling the GPIO API should take care of
configuring this semaphore. Can you file a ticket in our trac with
your original information and feel free to mention the workaround.
On Fri, Oct 30, 2015 at 6:38 PM, Steve B <sbattazzo at gmail.com> wrote:
> On Fri, Oct 30, 2015 at 3:25 PM, Steve B <sbattazzo at gmail.com> wrote:
>> Hi guys,
>> I've gotten around to updating my rtems src from the git repo, to a new
>> version that includes the GPIO API commit and the Beaglebone Black BSP work
>> contributed by Ketul Shah.
>> I'm trying to simply do
>> sc = rtems_gpio_request_pin(LED1, DIGITAL_OUTPUT, false, false, NULL);
>> assert(sc == RTEMS_SUCCESSFUL);
>> And at runtime I see:
>> assertion "rtems_semaphore_obtain(gpio_bank_state[bank].lock, RTEMS_WAIT,
>> RTEMS_NO_TIMEOUT ) == RTEMS_SUCCESSFUL" failed: file
>> line 1319, function: rtems_gpio_request_pin
>> I have called rtems_gpio_initialize() which I see is the function that
>> creates gpio_bank_state[bank].lock and this has returned RTEMS_SUCCESSFUL
>> before the above error happens.
>> I have also tried this on both Rev B and Rev C Beaglebone Black hardware,
>> with the same result.
>> Any thoughts on what might cause this?
> Disregard that, it's now solved!
> I just needed to define a value for CONFIGURE_MAXIMUM_SEMAPHORES at the
> bottom of my init.c and my program now runs.
> users mailing list
> users at rtems.org
More information about the users