Beaglebone Black GPIO Interrupt, and minor JTAG/gdb issue

Angelo Fraietta newsgroups at smartcontroller.com.au
Mon Jun 22 05:53:39 UTC 2015


When you have it going I would really like to see what you have done.

On Mon, Jun 22, 2015 at 3:43 PM, Steve B <sbattazzo at gmail.com> wrote:

> 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
>>
>>
>>
>>
>
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20150622/1a1466d5/attachment-0002.html>


More information about the users mailing list