INT_RDA4 stops working after a day or two

[guy]

PIC24FJ64GA308 , CCS PCD C Compiler, Version 5.040

The code works well but after a day or two the interrupt routine stops getting called although characters are still flowing in. A software reset fixes the problem.

The most obvious is to add ERRORS to the declaration but it's there. I don't see that I disable interrupts without enabling them back or anything like that. The code to clear the RXIF is a bug fix to an old compiler bug (not sure if it's still required but shouldn't cause the problem).
Any other ideas why the interrupt will not get called again?
Any 'elegant patch' ?
Thanks!

[Mike Walne]

Is main() still running and at the correct speed?

Mike

[guy]

[PCM programmer]

No interrupts of any kind ?

Can you add code to debug this ? Perhaps poll an i/o pin in a loop in
main(). Put a pullup and a switch on the pin. When the switch is pressed,
use printf to display the contents of all registers associated with interrupts.
Specifically, the Global interrupt flag and interrupt enables for peripherals.
This is a test that could be done in Release mode.

[guy]

Other interrupts are ok. Only INT_RDA4 is not called.
Debugging is tough since this is happening in a remote location and only after a day or two (sometimes only after a week).
I was hoping for someone to share an 'Oh, THAT!' insight or to find something in the disassembled code.
If not I would add a patch to reconfigure the UART and re-enable the interrupt if no data is coming in. Not very glorious and it leaves the HW/compiler bug hidden away...
If someone else has ideas please let me know.

[Ttelmah]

Get rid of this:

u4rxif=0;

The compiler does this automatically, unless you specify the interrupt with 'NOCLEAR'.

So the flag is being cleared twice. Wonder what happens if it interrupts _between_ the two clears?. With one, the interrupt won't be cleared, so the routine will be called again. With two?.....

[guy]

Thanks Ttelmah. As I said this was a fix to an old compiler bug. Since I'm out of better ideas I will remove it and see what happens.

Q: Does anyone have experience in INVOKING an interrupt call by setting the xxIF bit manually? Would it work? (assuming all other terms are met)

[Ttelmah]

Yes. I've done this.
I had a particular interface chip that during setup, could end up wanting service, but without the interrupt set. So after the setup I polled it, and if handling was required, set the interrupt.

Question on your original problem, was did the code have the same hang without the fix?. Presumably you had an old version where it didn't automatically clear this interrupt?. If it still gave the lockup then, then this isn't the problem, but I just wondered. I remember on one PIC finding that if you disabled interrupts on two successive instructions it gave problems.

I'd probably leave your clear in place, and try with the 'NOCLEAR' directive, which would ensure the compiler doesn't do it as well. That way it should work with both old and new compilers.

[guy]

[PCM programmer]

[guy]

PCM, in this case it's easier to follow Ttelmah's advice and give it a try than to recreate the whole setup. The specific problem (one specific interrupts stops working but returns to normal operation after a software reset) implies that it's probably not a hardware issue.
Cosmic rays??? Sounds like there's a good story there

[Ttelmah]

Cosmic ray effects on electronics, are one of the few 'real' things that can genuinely require a watchdog to fix. Very rare, but spend some time and you will get the odd memory cell flipping state without any normal influence. Normally so rare that these are out in the 'noise' caused by other effects, but they do happen....

Now on your problem. I only raised the double clear, because I had a problem a while ago, on another PIC, where it got into an odd state, if you did two clears on successive operations, with characters received in the instant between the two clears, being effectively lost. This is now an erratum for the chip concerned.

A 'non bench reproducible' fault, is always the worst one to track down. However I have to wonder if you could add some diagnostics to actually 'know' when the fault has occurred?. Does data come in a reasonably regular intervals on UART4?. If so, have you got a system clock?. If the answer to both of these is 'yes', then I'd be tempted to add a diagnostic routine, that in the event data is not seen in the interval, 'snapshots' everything associated with this UART. The actual state of the input pin. All the UART registers etc.. If you haven't got ROM available to store the data, reserve a page of the program memory, and do a single write to this. Then have the chip stop, and indicate that the event has happened, and you can read the data, and have a hope of finding out what is happening.

Is this happening on multiple chips?. If it is only one, then consider that it may simply be a faulty chip.

Beyond this, one (nasty) thought, is that something is actually changing the PPS register, so the pin is no longer deemed to be connected to the UART. This then stops receiving, and (of course) a reset re-programs the PPS data. This would fit well with the perceived behaviour. This is one of the reasons why the chip has locking to stop the bits being changed after boot (IOL1WAY). If you are not changing the PPS data after the program starts, then if you have NOIOL1WAY selected, try changing this.

When you say a 'RESET', do you mean just a reset (with MCLR), or a power-on-reset?. This makes a big difference. The latter, will also clear things like CMOS inputs that have become latched by a voltage spike, while the former will not. This affects where the problem may actually be.

You could also read the RS232_ERRORS byte, after fetching the character in the routine. If error bits have become set in this, then again it could help diagnosing what is going on.

[guy]

Thanks for the huge support everyone. I will go with my hunches and let you know if I find something substantial.

[gpsmikey]

Sounds like some sort of collision or state race - one thing that comes to mind is the possibility that while you are reading and clearing the interrupt for the incoming character, another one arrives. You now have one waiting without the interrupt being set since it was just cleared. Might be worth it to check for another character before exiting the ISR. Probably not likely at low baud rates, but at higher baud rates and ISR latency depending on what else is going on, it is possible.

mikey
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3

[Ttelmah]

Yes. Given the four character buffer: