INTCON bit 6 and INT_RDA not working from time to time

[darahayes]

Having had many months of intermittent problems with INT_RDA occasionally not working on a PIC18F258 device and reading many posts of similar apparently unresolved INT_RDA not working problems, I have had my doubts about the management of the INTCON registers as a function of turning on and off various interrupts at will in code. In my own case it appears after some debugging of this recurring problem that as a result of simply turning off and back on Global and various other timer interrupts (Timer 0-1-2 and 3) as well as INT_RDA itself, the compiler does not, it appears, seem to manage the bits in the the INTCON register correctly. It sometimes let bit six, the PEIE/GIEL interrupt enable bit some times get cleared. Once this bit is cleared the INT_RDA stops working. I don't understand how it's happening and I have reverted to hitting the hardware registers in my own code to get reliability. I don't understand as all I have been doing is turning all interrupts off starting with global and then the INT RDA and then Timers 0 to 3 and doing the reverse in the same enabling them back on in the same order.

[asmboy]

why are you needing to turn off interrupts, once enabled?

i use the #RDA int in a certified design for medical instrumentation with
18F parts , and extensive testing has never disclosed a fault condition.

then again - i don't disable any of my ints , once ENABLED,EVER!!!
i suspect a simple "misteak" but can't tell as you post so little....

got code that shows in detail what you attempt ??

[PCM programmer]

Post your CCS compiler version.

[darahayes]

My Compiler is PCWHD 4.141 , all I am doing is as I have described turning off several ints and back on again in the order I have described , if one never turns off the interrupts then I suppose its logical to suspect one will never ever write to the INTCON or PIR1 registers and all would be expected to remain constant, the point of my post was to point out that a possible reason for others having INT_RDA problems in an otherwise working project where they just drop off from time to time could be explained by the fact that in my code where all I have been doing was as described turning off and then quickly back on again various interrupts Bit 6 of INTCON was to blame for my INT _RDA problems , I may take a different approach and leave the ints running setting flags and just not service them in my main proc during these time critical parallel data bus data exchanges I have in my application where my first approach was to turn off interrupts .

What is the correct order for turning off and back on interrupts ?
thanks for your response to my first posting on this subject !

[Ttelmah]

OK.

The point about disabling/enabling interrupts, is that if you want them all off, just turn off the global, while if you want an individual one, then just disable the one you want. It is pointless to be turning them all off, and the global as well.

The comment does apply though as to 'why' you want them off. The only occasions normally are for something like writing the program memory, where (momentarily), they have to be off, and in most cases the compiler will already do this if it is necessary.

Generally you have to consider the effects of them being disabled, and the specific hardware requirements. So (for instance), a PORTB interrupt, requires PORTB to be read before it can be cleared. If you have the interrupts disabled, and then want to continue, ignoring any changes that occurred while they were off, you have to read the port before clearing/re-enabling this interrupt. Then make sure you have 'ERRORS' in the RS232 declaration, since if INT_RDA is disabled and a second character arrives, the UART will overflow, and be locked up, unless the error conditions are cleared. Adding 'ERRORS' makes the compiler automatically generate the code to clear this. For each interrupt, there are different 'requirements' that have to be met, depending on how you want the code to handle the missed events.

However the key question for your problem is 'printf'. There was a bug with some compilers, which appeared first in the mid V4 area, was fixed, then re-appeared again, they was fixed again, and was finally properly 'laid to rest' at about 5.012, where the compiler would disable the global interrupt inside printf statements, and not always re-enable it. It has to be disabled during certain types of table read operations, and they got 'overenthusiastic', cleared it, then tested if it was cleared, and at the end of the routine only re-enabled it, if it was enabled at the test. Since they had already disabled it, the re-enable got skipped....
A search here should find the threads about this, and all that is needed as a fix, is to re-enable the global bit after any printf, or update to the current compiler.

Best Wishes

[darahayes]

Ok thank you for the advice on using GLOBAL only , I don't use the Port B interrupt only timers and RDA and when doing fast data exchanges the timer values are about to change and therefore the interrupts that are occurring now are not valid as the timer values are about to change , and I only want to react to the new changed timer value interrupts , I use the errors on my USART and use the over run error to catch strings that have gone astray during other busy times and make a request to retry from the RS232 source, the RS232 is software handshaked so if no reply to source , it will ask again anyhow , so I never lose any RS232 exchanges . Thanks for your advice I will proceed with caution and only use the GLOBAL for turning off interrupts
thanks