Forums

Chipcon 2430: strange interrupt behaviour

Started by Henk Kok December 4, 2009
Dear group,

We are in the process of migrating our project from the CC2430 to
CC2530, and to try to make the migration steps a bit smaller (yeah
right!) we first do the migration from the Keil to the IAR compiler.
During this transition, I am running into some weird problems.

After some time, any interrupt with a priority less than or equal to
the timer1 interrupt priority, does not get called anymore. This
suggests that the processor is hanging in a timer1 interrupt, but this
is not the case: our main loop is still running. Nevertheless, the IRQ
mask is correct, EA=1, even the IRQ flag for timer 1 is set, but the
ISR is not called. Also, when in this situation the RF interrupt
should be called (RFIM and RFIF have overlapping bits, S1CON=0x03,
EA=1, et al) no RF ISR is called, when the RF interrupt has a priority
less than or equal to the timer1 interrupt.

Unfortunately I cannot post any code here (copyrights and such) but I
hope my description rings a bell with someone and can give me a hint.

Things that I have investigated: all SFR that are relevant have the
same value under Keil and under IAR. Things that I consider not
relevant are e.g. status bits of the UARTs, timer values and random
values. This suggests that a timing issue is bringing the processor in
a certain state in which it does not fire the ISR anymore, even though
all conditions for doing so, are met.

Who can shed some light on this problem in these dark December days? I
myself am still going to dig deeper and I will add info if I find
any. :)

Best regards,

- Henk Kok.
Henk Kok wrote:

> After some time, any interrupt with a priority less than or equal to > the timer1 interrupt priority, does not get called anymore. This > suggests that the processor is hanging in a timer1 interrupt, but this > is not the case: our main loop is still running.
You are not alone... Some years ago we've experienced the same behavior on a (don't recall) brand of a '51 chip. It appeared that the tail of the ISR routine was executed twice! (we did put a 'INC var' on entry of the ISR and a 'DEC var' just before the RETI instruction to prove this behavior). After some digging around we have decided to drop the priority issue, i.e. gave all interrupts the same priority. Good luck hunting. -- Wil