<div dir="ltr">Thanks, Chris!<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 22, 2015 at 1:36 PM, Chris Johns <span dir="ltr"><<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
On 22/06/2015 3:13 pm, Steve B wrote:<br>
> Hello all,<br>
><br>
> I'm playing around with getting an interrupt service routine going on<br>
> Beaglebone Black.<br>
><br>
> I am aware that Ketul with GSoC is working on the GPIO code but for now<br>
> I have just decided to manually peek and poke the registers from my<br>
> application code, as I didn't see anything IRQ related yet in the patch<br>
> on the github site for that effort.<br>
><br>
> Here's what I have done:<br>
> 1. Set GPIO1_13 as an output, physically jumped GPIO1_13 (P8, 11) to<br>
> GPIO1_12 (P8, 12).<br>
> 2. Set bit (1 << 12) to the GPIO_IRQENABLE_SET_1 and<br>
> GPIO_IRQENABLE_SET_0 registers for GPIO1, per AM338x technical reference<br>
> manual.<br>
> 3. Set bit (1 << 12) to the GPIO_RISINGDETECT register for GPIO1.<br>
> 4. Installed an ISR to GPIO number 98 or 99 which is the IRQ for GPIO1.<br>
><br>
> I hacked this into the "ticker" demo from examples-v2 and added a line<br>
> of code to toggle GPIO1_13 in the periodic task to stimulate the interrupt.<br>
><br>
> I may be close but something is not quite right here.<br>
> Whenever the interrupt happens, the CPU resets and runs the uboot that<br>
> is stored on its eMMC instead of going to my ISR. Any thoughts on why<br>
> that might be?<br>
> Attaching my code here also. Sorry it's kind of an ugly hack for now, I<br>
> just punched a few lines of code into the ticker example.<br>
><br>
> And an unrelated note, anytime I do a "load" and run my application<br>
> through GDB, if I try to halt and load again, the CPU always starts from<br>
> uboot on the eMMC and I have to halt and load one extra time. This is<br>
> with flyswatter2 and OpenOCD. Anyone experienced this?<br>
<br>
</div></div>I typically reset and reload each debug cycle.<br>
<br>
With the Beagle Board XM I used when Ben and I played with this stuff a<br>
while ago I loaded the MIO code from uboot with OpenOCD via GDB. The<br>
details can be found here:<br>
<br>
<a href="https://git.rtems.org/rtems-tools/tree/tester/rtems/testing/bsps/beagleboardxm.mc" rel="noreferrer" target="_blank">https://git.rtems.org/rtems-tools/tree/tester/rtems/testing/bsps/beagleboardxm.mc</a><br>
<br>
The GDB fragment of interest is:<br>
<br>
  target remote kaka:3333<br>
  mon beagleboard_xm_mlo /path/bb/uboot/u-boot/MLO<br>
  load<br>
  b _Terminate_CPU_Fatal_halt<br>
  continue<br>
<br>
And the OpenOCD TCL for beagleboard_xm_mlo can be found here:<br>
<br>
 <a href="https://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/beagle/simscripts/bbxm.cfg" rel="noreferrer" target="_blank">https://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/beagle/simscripts/bbxm.cfg</a><br>
<span class="HOEnZb"><font color="#888888"><br>
Chris<br>
</font></span></blockquote></div><br></div>