Beaglebone Black GPIO Interrupt, and minor JTAG/gdb issue

[Steve B]

UPDATE:
Found my answer on the ISR causing reset.
The answer was: "Do not call puts() from the ISR!"
I don't really know why this is the case, but I was a little hesitant about
using the puts() in the first place, but did it anyway out of laziness. If
I really wanted to print info I guess I could make another task and trip it
with a semaphore or similar from the ISR.

Instead I did something with the user LEDs to convince myself that the ISR
was being reached, and now I'm happy.

Still not sure what's up with JTAG loading.. seems like I have to reset the
processor between exe reloads.

Steve



On Sun, Jun 21, 2015 at 10:13 PM, Steve B <sbattazzo at gmail.com> wrote:

> 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/d7a56303/attachment-0002.html>