Beaglebone Black GPIO Interrupt, and minor JTAG/gdb issue

Fri Jul 3 06:58:04 UTC 2015

I have the program running now. Have not tried the interrupts yet but will
give it a quick go next week. From the code it looks like you do a toggle
on all 4 LEDS when an interrupt occurs. Is that correct?

On Wed, Jul 1, 2015 at 7:10 AM, Angelo Fraietta <
newsgroups at smartcontroller.com.au> wrote:

> Thanks. I am still getting the error trying to make.
>
> On Wed, Jul 1, 2015 at 3:15 AM, Steve B <sbattazzo at gmail.com> wrote:
>
>> Hi Angelo,
>>
>> You should just need these three files in the same folder, and you need
>> to have the RTEMS compiler in your path and the RTEMS_MAKEFILE_PATH defined.
>>
>> Steve
>>
>> On Mon, Jun 29, 2015 at 8:00 PM, Angelo Fraietta <
>> newsgroups at smartcontroller.com.au> wrote:
>>
>>> That would be great. Thanks
>>>
>>> On Tue, Jun 30, 2015 at 11:50 AM, Steve B <sbattazzo at gmail.com> wrote:
>>>
>>>> Hi Angelo. I just used the makefile from an application in the
>>>> examples-v2 repo that's available on github, and I also copied some header
>>>> file from there into my application folder because I wanted my own folder
>>>> tree instead of a new one in examples-v2.
>>>> I am away from the office today but can send it tomorrow if you need
>>>> it.
>>>> On Jun 28, 2015 4:45 PM, "Angelo Fraietta" <
>>>> newsgroups at smartcontroller.com.au> wrote:
>>>>
>>>>> Do you have a makefile that will enable me to build the app?
>>>>> Thanks
>>>>>
>>>>> On Mon, Jun 22, 2015 at 4:14 PM, Steve B <sbattazzo at gmail.com> wrote:
>>>>>
>>>>>> Sure, here is an updated version.
>>>>>> I erased commented out code lines that I wasn't using anymore.
>>>>>>
>>>>>> The "init" task sets up GPIO (user LEDs as outputs) and interrupt
>>>>>> stuff (GPIO1_12 as a rising edge trigger), and then ducks out of the way.
>>>>>>
>>>>>> "Test task" is periodic, runs every two seconds and toggles GPIO1_13
>>>>>> on and off.
>>>>>>
>>>>>> With GPIO1_13 shorted to GPIO1_12), the ISR fires off, and toggles
>>>>>> all four LEDs. Since we're waiting for the periodic task to toggle twice,
>>>>>> the LEDs will toggle once every four seconds.
>>>>>>
>>>>>> This isn't really the "right" way to do this.. so if there weren't
>>>>>> already plans to integrate this functionality into the GPIO API that's in
>>>>>> the pipeline, I'd like to help get it in there!
>>>>>>
>>>>>> Steve
>>>>>>
>>>>>> On Sun, Jun 21, 2015 at 10:53 PM, Angelo Fraietta <
>>>>>> newsgroups at smartcontroller.com.au> wrote:
>>>>>>
>>>>>>> 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/20150703/480f802d/attachment.html>