global interrupts disabled mysteriously

dgi · Joined: 07 Jan 2004 Posts: 11 Location: Philadelphia, USA

I am using CCS 3.249 (having read that it is the most stable) to program a PIC18F2420, crystal clocked at 20 Mhz.

My program sets up a single periodic interrupt to perform a high priority polling task, and enables it like this:

Ttelmah · Guest

What is in your interrupt handler?.
The interrupts are disabled by the hardware, when the handler is called. If this has a problem, and overruns, or jumps back into the main, then you will see the effect described.

Best Wishes

dgi · Joined: 07 Jan 2004 Posts: 11 Location: Philadelphia, USA

Thank you Ttelmah for the advice. I haven't found anything wrong in the interrupt yet, but I may have found the problem in main(). My printf actually itself calls printf:

Ttelmah · Guest

Probably not directly.
Though recursion (which this is), is not supported, printf itself is normally coded as 'inline', and in this case, the printf being called uses a different output routine to the caller, so it might actually work!.
However though it'll probably crash the code, I'd not expect it to disable interrupts.
The way to do this, is to not use printf in the output routine. Just output the two hex digits yourself.
The other things that would cause the problem, is if printf is being called in the interrupt handler, since then interrupts will be disabled in printf...

Best Wishes

davekelly · Joined: 04 Oct 2006 Posts: 53 Location: Berkshire, England

I am using 3.249 also, for the 18F242

I have also experienced this problem, and am still trying to track it down.

dgi · Joined: 07 Jan 2004 Posts: 11 Location: Philadelphia, USA

Thank you for the guidance, folks.

Working or not, I removed all recursive function calls as described above. However, I still have the problem of interrupts getting disabled after several minutes of the program running.

I still don't know why the global interrupt enable bit gets cleared in the middle of execution. I don't know whether it is a problem in the interrupt, in the main program, or in the compiler. But here is what I have done so far, which seems to help. I instrumented my code so that I can figure out exactly where GIE get disabled:

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

Spiteful · Joined: 09 Jul 2007 Posts: 2

I have same problem Sad

CCS v3.236
PIC12F629

defined:

unsigned int8 TRISIO;
#locate TRISIO=0x85
#bit TRISIO5=0x85.5
#bit TRISIO4=0x85.4
#bit TRISIO3=0x85.3
#bit TRISIO2=0x85.2
#bit TRISIO1=0x85.1
#bit TRISIO0=0x85.0

compilled:

.................... // pin A5 as input
.................... TRISIO5 = 1;
0345: BSF 03.5
0346: BSF 05.5
0347: BCF 03.5
0348: CLRF 2E
0349: BTFSC 0B.7
034A: BSF 2E.7
034B: BCF 0B.7
....................

when 2E is:

02E @INTERRUPT_AREA

What can i do with it? Why compiller clearing 2E and test GIE?

Ttelmah · Guest

0x2E, contains a value used by the compiler to reflect the interrupt status.
The compiler is checking if interrupts are enabled, and changing the value of bit 7 in this register to reflect this.
On these chips, if you change the TRIS, it can result in an interrupt on change being triggered.
This not 'the same problem'. The original poster had the GIE bit being changed. In your case, it is only being tested. In your case, there may well be some logic to this (though you would have to look at where 0x2E is used to work out the implications).

Best Wishes

Spiteful · Joined: 09 Jul 2007 Posts: 2

Thanks.

nurquhar · Joined: 05 Aug 2006 Posts: 149 Location: Redditch, UK

Compiler v4.130

I found this post after having similar problem with printf() turning off the global interrupt enable.

In my case I am using printf() with my own putc() to handle a data output from a timer interrupt function. My putc() accesses some 8 bit ints used within the timer isr(), this should be safe because the accesses will be atomic. CCS, as described above turns off GIE in printf() prior to calling my putc() because it thinks I will be changing a variable used with an interrupt. Although in my case this is misguided and not neccessary the compiler does not generate any Warnings to give me a clue as to why my program hangs unexpectedly.

If CCS is smart enough to put the GIE off when it sees something being used inside AND outside the interrupt (even though I don't want it) it could least generate a warning Question

Even better it could have looked at the access and decided they are 8bit and thererfor safe. THus no need to turn GIE off. Perhaps this is asking too much of the compiler.

I am fixing my code by using a somewhat brutel GIE = 1 inside my putc().

This is my code and build info :

Ttelmah · Joined: 11 Mar 2010 Posts: 19513

Seriously, 'of course' it has to disable interrupts. I'm amazed it doesn't just explode!....
You do realise that the routine you use in a printf, is called repeatedly for every character in the output?. Your 'pwmc_putc' routine will be called up to 16 times, with three of the calls depending on the value of 'ch'. Each call then changes the value of pwmc_ch, inside itself, and the routine must ensure that variables don't change between successive calls.
If you want to send text characters to the ISR, use sprintf to generate a string, and transfer these yourself.

nurquhar · Joined: 05 Aug 2006 Posts: 149 Location: Redditch, UK

Dear Ttelmah

Yes you are correct pwmc_putc does alter the pwmc_ch. But the code has been carefully designed ! pwmc_ch is only altered in the interrupt when pwmc_cnt IS NOT zero. pwmc_putc only alters it when pwmc_cnt IS zero.

nurquhar · Joined: 05 Aug 2006 Posts: 149 Location: Redditch, UK

Thinking some more about using printf() inconjuction with a user supplied putc(). It seems there must be many many applications that use it to push data into a FIFO buffer that then use an interrupt handler to pop the data for output to the hardware.

This is a pretty standard scenario for an interrupt driven serial port transmitter, a model I first used on Z80's back in the 80's. For the buffer you have a head & tail pointer and a contents count. The interrupt takes data out at the head pointer and reduces the count. The putc() puts data in at the tail pointer and increases the count. The count is used for the buffers tests, ie buffer full, empty or space left.

If you can use an atomic operation operation for the buffer contents count there should be no need to disable interrupts for the buffer push in the putc() function. If you were using a 16bit buffer count on an 8bit CPU then you would have to disable interrupts whist the count is being changed in putc() to prevent the interrupt "seeing" a half changed value.

My code above effectivly uses a this model but with a 1 byte buffer size.

My beef with the CCS complier is that it does'nt warn that it is disabling the interrupts prior to entering the users code.

What would be nice to have is way of telling the compiler that it does not need to take responsibility of checking if a certain variable is used inside and outside an interrupt handler and disable interrupts to protect it.

Some new preprocessor directive like this might do it.

#INT_IGNORE
int8 pwmc_ch ;

You never know CCS might be looking for something to do Wink

Ttelmah · Joined: 11 Mar 2010 Posts: 19513

The point is the compiler can't tell this. It looks for simple things. "can this routine modify something that is inside another routine called in the interrupt". If answer is 'yes', is _has_ to protect the code.
You can write the code so there is no possibility of such a crossover, and if so, then the compiler will not implement it's protection.