More debugging after studying the source.
1) I can successfully load the hal_bb_gpio driver if I only configure the LEDs.
loadrt hal_bb_gpio user_leds=0,1,2,3
After loading the driver, I can create a thread, add the write function
to the thread, start threads, and blink the LEDs. Some other code is
also accessing two of the LEDs, you can see them flicker as the two
competing sources write to the hardware.
2) I exercised some of the error-detection paths by invoking it
with various input pins:
loadrt hal_bb_gpio input_pins=700
Jul 31 21:37:59 beaglebone rtapi:0: rtapi_app_main(hal_bb_gpio): -1 Operation
not permitted
Jul 31 21:37:59 beaglebone msgd:0: hal_lib:522:rt hal_bb_gpio: ERROR: invalid
pin number '700'. Valid pins are 801-846 for P8 pins, 901-946 for P9 pins.
Jul 31 21:37:59 beaglebone msgd:0: rtapi_app:522:user
rtapi_app_main(hal_bb_gpio): -1 Operation not permitted
loadrt hal_bb_gpio input_pins=801
Jul 31 21:39:01 beaglebone rtapi:0: rtapi_app_main(hal_bb_gpio): -1 Operation
not permitted
Jul 31 21:39:01 beaglebone msgd:0: hal_lib:522:rt hal_bb_gpio: ERROR: pin p8.01
is not available as a GPIO.
Jul 31 21:39:01 beaglebone msgd:0: rtapi_app:522:user
rtapi_app_main(hal_bb_gpio): -1 Operation not permitted
3) I successfully loaded it using input pin 803 (header P8, pin 3)
loadrt hal_bb_gpio input_pins=803
Jul 31 21:39:54 beaglebone msgd:0: hal_lib:522:rt memmapped gpio port 1 to
0xb66a5000, oe: 0xb66a5134, set: 0xb66a5194, clr: 0xb66a5190
Jul 31 21:39:54 beaglebone msgd:0: hal_lib:522:rt pin 3 maps to pin 1-6, mode 85
Now it gets interesting.
I unloaded the driver:
unloadrt hal_bb_gpio
And tried reloading it with the same pin number, just as a
test before moving to a different pin number.
loadrt hal_bb_gpio input_pins=803
this time it didn't work
Jul 31 21:40:25 beaglebone rtapi:0: rtapi_app_main(hal_bb_gpio): -1 Operation
not permitted
Jul 31 21:40:25 beaglebone msgd:0: hal_lib:522:rt hal_bb_gpio: ERROR: pin p8.03
is not available as a GPIO.
Jul 31 21:40:25 beaglebone msgd:0: rtapi_app:522:user
rtapi_app_main(hal_bb_gpio): -1 Operation not permitted
That error message is printed when the "claimed" field
of the pin structure is non-zero. Those fields are set to
zero in beaglebone_gpio.h, and I expected that unloading
and reloading the module would reset them...
I completely exited from HAL ("quit" at the halcmd prompt)
and then tried again loading multiple pins. Success.
loadrt hal_bb_gpio input_pins=803,804,805,806
Jul 31 21:54:43 beaglebone msgd:0: hal_lib:960:rt memmapped gpio port 1 to
0xb6717000, oe: 0xb6717134, set: 0xb6717194, clr: 0xb6717190
Jul 31 21:54:43 beaglebone msgd:0: hal_lib:960:rt pin 3 maps to pin 1-6, mode 85
Jul 31 21:54:43 beaglebone msgd:0: hal_lib:960:rt pin 4 maps to pin 1-7, mode 85
Jul 31 21:54:43 beaglebone msgd:0: hal_lib:960:rt pin 5 maps to pin 1-2, mode 85
Jul 31 21:54:43 beaglebone msgd:0: hal_lib:960:rt pin 6 maps to pin 1-3, mode 85
Completely exited from HAL again, and tried pin 807:
loadrt hal_bb_gpio input_pins=807
CRASH!
Jul 31 21:56:57 beaglebone msgd:0: hal_lib:1098:rt memmapped gpio port 2 to
0xb6668000, oe: 0xb6668134, set: 0xb6668194, clr: 0xb6668190
Jul 31 21:56:57 beaglebone msgd:0: rtapi_app:1098:user signal 7 - 'Bus error'
received, dumping core (current dir=/home/machinekit/grinder)
Jul 31 21:56:57 beaglebone msgd:0: rtapi_app:1098:user --- rtapi_app
backtrace: ---
Jul 31 21:56:57 beaglebone msgd:0: rtapi_app:1098:user ERROR decoding
backtrace: no debug info in ELF executable (-1)
Jul 31 21:56:57 beaglebone msgd:0: rtapi_app:1098:user ERROR decoding
backtrace: no debug info in ELF executable (-1)
Jul 31 21:56:57 beaglebone msgd:0: rtapi_app:1098:user ERROR decoding
backtrace: no debug info in ELF executable (-1)
Jul 31 21:56:57 beaglebone msgd:0: rtapi_app:1098:user ERROR decoding
backtrace: no debug info in ELF executable (-1)
Jul 31 21:56:57 beaglebone msgd:0: rtapi_app:1098:user --------------------
Jul 31 21:56:57 beaglebone msgd:0: rtapi_app exit detected - scheduled shutdown
Jul 31 21:56:59 beaglebone msgd:0: msgd shutting down
Jul 31 21:56:59 beaglebone msgd:0: zeroconf: unregistering 'Log service on
beaglebone.local pid 1091'
Jul 31 21:56:59 beaglebone msgd:0: log buffer hwm: 0% (5 msgs, 474 bytes out of
524288)
Jul 31 21:56:59 beaglebone msgd:0: normal shutdown - global segment detached
based in the info written to the log file, it successfully executed
the configure_gpio_port() call on line 244, but never reached the
rtapi_print() call on line 250. (caveat - maybe it did execute line
250 but the message never made it to the log due to a crash
somewhere later in the driver code that took out the logging
mechanism).
Maybe a clue: pins 803-806 which worked are in port 1, pin 807
that crashed is in port 2...
Sensing a pattern. Tried pin 817, which is in port 0. No problem.
Tried pin 818, port 2. Crash. It's getting late, I'm not going to
try every single pin unless someone thinks its worthwhile.
While looking at the table in beaglebone_gpio.h I noticed
something else suspicious. The entry for header 8 pin 6 is on
line 80. The control offset field is 0x803. The control offset
field for every other pin is a multiple of 4. Typo? Note that
pin 6 worked, but pin 7 didn't. So I don't think that typo
caused the crash.
I'm hoping that Charles or Ian or someone else who knows
this driver can help me figure out what is going on...
One other caveat: I am looking at the source on github.
I am running the version of MachineKit from this image:
bone-debian-7.9-machinekit-armhf-2016-02-15-4gb.img.xz
downloaded from this location back in February:
http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#BBW.2FBBB_.28All_Revs.29_Machinekit
According to github the .h file hasn't changed since 2013,
and the .c file since May 2015. So hopefully I'm looking
at the same code I'm running.
--
John Kasunich
[email protected]
--
website: http://www.machinekit.io blog: http://blog.machinekit.io github:
https://github.com/machinekit
---
You received this message because you are subscribed to the Google Groups
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.
