<div dir="ltr"><div><div><div><div>UPDATE:<br></div>Found my answer on the ISR causing reset.<br></div>The answer was: "Do not call puts() from the ISR!"<br></div><div>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.<br></div><br></div><div>Instead I did something with the user LEDs to convince myself that the ISR was being reached, and now I'm happy.<br><br></div><div>Still not sure what's up with JTAG loading.. seems like I have to reset the processor between exe reloads.<br></div><div><br></div>Steve<br><br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jun 21, 2015 at 10:13 PM, Steve B <span dir="ltr"><<a href="mailto:sbattazzo@gmail.com" target="_blank">sbattazzo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Hello all,<br><br></div>I'm playing around with getting an interrupt service routine going on Beaglebone Black.<br><br></div>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.<br><br></div><div>Here's what I have done:<br></div><div>1. Set GPIO1_13 as an output, physically jumped GPIO1_13 (P8, 11) to GPIO1_12 (P8, 12).<br></div><div>2. Set bit (1 << 12) to the GPIO_IRQENABLE_SET_1 and GPIO_IRQENABLE_SET_0 registers for GPIO1, per AM338x technical reference manual.<br></div><div>3. Set bit (1 << 12) to the GPIO_RISINGDETECT register for GPIO1. <br></div><div>4. Installed an ISR to GPIO number 98 or 99 which is the IRQ for GPIO1. <br><br></div><div>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.<br><br><div>I may be close but something is not quite right here.<br></div>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?<br>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.<br><br></div><div>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?<br><br></div><div><br></div><div><br></div><div>Thanks,<br><br></div><div>Steve<br></div><div><br></div><div><br><br></div></div>
</blockquote></div><br></div>