External Interrupt Problem

[neilelph]

I am trying to get the External Interrupt (on RB0) to work on a PIC16LF877.

Unfortunately my code will not work or simulate as I would like it to - in fact the interrupt just doesn't work!

I am using MPLAB V8.84 and the PCW C Compiler.

My interrupt code is written as below:

[temtronic]

Without seeing the whole, real program ,it's hard to tell....

Since you disable the interrupt within itself, it could have executed before you think it should and is now disabled...

What triggers the ISR? Are you sure that it can or is being triggered?

hmm..simulation....if Proteus...throw it away, it doesn't work ! See ANY previous 'simulation' posts.

[neilelph]

The interrupt is to allow a delayed start feature to my tool. It is only ever required once.

My tool is controlled by an ARM Processor and the PIC Monitors vital functions. If a delayed start has been configured by the user, the ARM Processor programs an alarm into an RTC and then tells the PIC to shut everything down apart from its own power supply. At this point the PIC arms the External Interrupt which is connected to the RTC and then waits. When the RTC alarms, the PIC turns on all other power supplies and the ARM Processor resumes overall control. The PIC External Interrupt is never required again.

Full code below.

[Ttelmah]

Seriously, you need to learn how to debug problems. You trim away code, till you only have the parts causing the problem. You then have a minimum program showing he problem that can be posted if you still can't see it for yourself.
As it is, I doubt if anyone will even bother to look at a program this large, especially given that it is still incomplete. Things like the state values are not defined, etc. etc...
Separately, forget simulators. The only one that is reasonably 'worthwhile', is MPLAB, and this is slow, and still doen't handle quite a few peripherals. Get an ICE, or ICD.
Most likely thing is that the interrupt is being immediately called, and then cleared. _Read the data sheet_. What can happen when you change the interrupt edge?.

Best Wishes

[neilelph]

Seriously, if you've nothing helpful to post, then don't bother.

I only posted the whole code, because it was requested. I have been through various debug procedures and not found the problem. I have limited tools as I work for a tight fisted company.

I didn't just post on here as soon as I had a problem, I only post so I can get a second pair of eyes looking at the problem that may be staring me in the face.

But thanks for your comments.

[jeremiah]

The MPLAB simulator he is speaking of is absolutely FREE. I would suggest the one with MPLAB 8.whatever IDE versus MPLAB X IDE, since MPLAB X is very new and still buggy.

Try the following program:

[Ttelmah]

It was 'requested', because what you posted originally was not enough to give even the faintest hint of what your problem might be. However Temtronic, like me, assumed you would have at least started to try to actually debug the problem yourself, and would therefore have a trimmed set of code.

Your postings are a bit like a person having trouble getting a car to track straight, who posts a picture of the steering wheel, and says "I can't get this to work", and then when asked to show some more information, instead of showing perhaps some details of the steering arms and geometry, instead shows a photo of the car....

My comment about looking in the data sheet, at what happens when you change the interrupt edge, still applies.

Best Wishes

[Mike Walne]

I fully endorse what the other guys are saying.

Read the CCS forum guide.

Amongst other things, it advises you to post MINIMUM compilable code which allows us to diagnose your problem.

I, for one, will not touch simulator issues, nor plough my way through mountains of irrelevant code.

The advice you get here is freely given by experts who normally charge $$$$/££££ for their services.

You need to make it easy for them to help you.

Mike

[ckielstra]

I agree with Ttelmah that the problem might be in how you enable the interrupt, an essential instruction is missing here. Check the datasheet.
A similar problem lures with the Timer1 interrupt enabling.

I normally don't like long code postings but nonetheless had a quick look at it:
1) I don't see code for initializing the variables. Perhaps this is done in the missing declaration code? At least loopCount2 has a problem as it is never reset again.
2)

[neilelph]

Apologies if I seemed over-sensitive to criticism, but I was only responding to a request that I perhaps took too literally! I also clearly state the tools I have used in my first post (free or otherwise).

I accept constructive criticism openly, but there are ways of doing it without jumping down someones throat. I am also a professional who designs digital and analogue electronics along with developing firmware and software, but I can't apologise for not being an expert in all!

I thank you all for your feedback and input - it is very much appreciated. I also provide help to others on forums occasionally, so it's not a one way street with me.

Thanks again.

[RF_Developer]

Many of those who provide most of the help here are also professionals, myself included. I can only speak for myself: I post in my tea and lunch breaks. I do it because I want to help.

I have limited time. I cannot read through and understand more than a few tens of lines of code in an example. I can't wade through lines and lines of application specific code that's (probably) irrelevant to the problem.

What we want, and can deal with, is a complete but very short code example that will compile and show the problem. That means we expect the poster to have isolated the problem to a significant extent. It also gets round the problem of IP issues by not requiring the posting of proprietary code. It also means the "helped" needs to do some of the work. In return we give freely of our own time to help as much as we can. Sometimes though that's not good enough, as we can't know everything.

Only if that fails is it useful to cast the net wider.

That though is what we'd like to happen. What actually usually happens is that someone posts a very vague "my stuff doesn't work", then when requested for more information, gives a nearly complete info dump of their code, often missing out vital information such as fuse set-up, PIC type, compiler version and so on and expects us to work out what their problem is without even telling us the symptoms. Oh yes, and they've generally not bothered to read the CCS manual, which to be fair is not always correct or updated to reflect the current state of the tool set.

Do you still wonder why some of us are a more than a little twitchy and touchy about what goes on here?

RF Developer.

PS: My tea is now cold and I've been moaned at to get my timesheets for March done....

[neilelph]

Again, I apologise for any offence caused.

However, as mentioned already I have done all the work in debugging to the point where I needed help and my first post shows this. I only posted the whole code in response to a request. I don't expect anyone else to do my work for me.

I fully understand where you are coming from with regards to time etc., but I also work under pressured conditions and tight timelines but I don't shoot people down in flames for doing what was requested of them (albeit I accept I misinterpreted what was being asked).

Again, I thank and respect all comments and help provided, and have no bones to grind with anyone.

Thanks again.

[Gabriel]

From your post...