Beaglebone Black GPIO Interrupt, and minor JTAG/gdb issue

[Steve B]

Hello all,

I'm playing around with getting an interrupt service routine going on
Beaglebone Black.

I am aware that Ketul with GSoC is working on the GPIO code but for now I
have just decided to manually peek and poke the registers from my
application code, as I didn't see anything IRQ related yet in the patch on
the github site for that effort.

Here's what I have done:
1. Set GPIO1_13 as an output, physically jumped GPIO1_13 (P8, 11) to
GPIO1_12 (P8, 12).
2. Set bit (1 << 12) to the GPIO_IRQENABLE_SET_1 and GPIO_IRQENABLE_SET_0
registers for GPIO1, per AM338x technical reference manual.
3. Set bit (1 << 12) to the GPIO_RISINGDETECT register for GPIO1.
4. Installed an ISR to GPIO number 98 or 99 which is the IRQ for GPIO1.

I hacked this into the "ticker" demo from examples-v2 and added a line of
code to toggle GPIO1_13 in the periodic task to stimulate the interrupt.

I may be close but something is not quite right here.
Whenever the interrupt happens, the CPU resets and runs the uboot that is
stored on its eMMC instead of going to my ISR. Any thoughts on why that
might be?
Attaching my code here also. Sorry it's kind of an ugly hack for now, I
just punched a few lines of code into the ticker example.

And an unrelated note, anytime I do a "load" and run my application through
GDB, if I try to halt and load again, the CPU always starts from uboot on
the eMMC and I have to halt and load one extra time. This is with
flyswatter2 and OpenOCD. Anyone experienced this?



Thanks,

Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20150621/80e2dd41/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: init.c
Type: text/x-csrc
Size: 4580 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/users/attachments/20150621/80e2dd41/attachment.bin>