Triggering an interrupt in firmware

picj1984 · Joined: 01 Mar 2010 Posts: 73

Hi guys,

I feel silly asking this, but I'm spinning my wheels trying to figure out how to do it, and my searches have been fruitless. How do you trigger an interrupt in the code itself?

I'm thinking it is the opposite of the clear_interrupt() function.

Basically, I have a button that I press that triggers an external interrupt, and I'd like to be able to trigger it in code as well.

Thx

stinky · Joined: 05 Mar 2012 Posts: 99 Location: Central Illinois

You'll need to confirm in your data sheet if the interrupt flags you wish to access are writable. Assuming they are, you could map to the desired special function register.

However, why?

Are you saying that you'd like an external interrupt, and a branch of software to execute the same code? Seems like this is just a flow control issue.

temtronic · Posted: Sat May 10, 2014 1:44 pm

off the top of my head....if your program sets the appropriate interrupt flag bit of it's interrupt control register, that 'should' work....
I recall those bits are R-W types ....

I can't test though as I'm working on the D-14 tractor(higher priority interrupt !!)

hth
jay

Mike Walne · Joined: 19 Feb 2004 Posts: 1785 Location: Boston Spa UK

I just checked a random PIC data sheet.

Confirms Jay's suspicion, xxxIF's are R/W.

You will, of course, have to check the flag you want to use is indeed R/W.

Though you are not telling us why you should want/need to do it.

Mike

Humberto · Posted: Sat May 10, 2014 6:20 pm

I think you can do it, bearing in mind the previous comments and considerations stated.
Talking seriously, I can not imagine: for what reasons you have to do such test?

regards,
_________________
Humber

picj1984 · Joined: 01 Mar 2010 Posts: 73

Now that I've actually thought it through... it doesn't make sense for me to do it this way. I appreciate the responses though!

temtronic · Posted: Sat May 10, 2014 9:46 pm

One reason to do it, is part of a device 'self-calibration' routine where the 'external event' is needed to trigger the 'calibration routine'. Done this way the overall timing would be the same as 'real life'.
'event happens'
ISR is entered...
stuff done...
ISR is exited...
'calibration completed'.

hth
jay

Battery David · Joined: 01 Feb 2010 Posts: 25

This is something I have been wondering. I have a customer who wants tests for every possible thing and I have ISRs for things like oscillator failure. How do you test for something like that? I'll just force the interrupt and trust that the hardware will set the bit automatically in case the oscillator actually does fail.

asmboy · Joined: 20 Nov 2007 Posts: 2128 Location: albany ny

newguy · Joined: 24 Jun 2004 Posts: 1909

Battery David · Joined: 01 Feb 2010 Posts: 25

Sadly, I'm using the internal oscillator.

RF_Developer · Joined: 07 Feb 2011 Posts: 839

Ttelmah · Joined: 11 Mar 2010 Posts: 19537

Yes.

You need to understand that the PIC needs a clock to run. Can't do anything if the clock is not running. What it has is a circuit to detect if an external oscillator is running, and if it isn't, if 'fail safe clock monitoring' is enabled, it switches to the internal oscillator, and sets the oscillator failure flag. Running on the internal oscillator there is no such fallback.

Best Wishes

temtronic · Posted: Tue May 13, 2014 7:51 pm

One possible 'dead PIC' detector/display is to have the PIC trigger a 'retriggerable' one shot( 74123 ) every so often. If it fails to do so within the time allowed the oneshot turns on an LED. This does require an I/O pin,74123 and LED but does visually confirm the PIC has stopped.

Another 'philosophy' might be the POST(Power On Self Test) that PCs have had since day one.Before a 'test' is made a number is sent to say the LCD or LED unit. When it passes the test, the number is incremented and carries on...
if the unit fails a test, the number tells you which test failed.

depending on the PICs memory anything/everything could be tested...

just food for thought
hth
jay