<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>