Sometimes interrupts do not work after unexpected reset.

[Eric_t]

Hi.

I have a firmware that runs on MC9S12XDT512 and MC9S12XEQ512 controller.

There is bug in my code that causes (after few days of operation) unexpected reset.

I do not know yet what causes the reset, but the big problem is that after the unexpected reset, the interrupts sometimes do not work.

Please not that most of the times the interrupts work fine.

After the initialization of the controller, I have a routine that waits modulus timer to trigger an interrupt. The trigger never happens and uC waits for ever.

I have made hotsync and I saw that hiwave shows that maskable interrupt was enable, modulus timer was enable and run (TEN=1), but interrupt trigger never comes.

Also, I have found out that all maskable interrupts do not work.

It looks like as if the maskable interrupts do not work anymore.

I have run out of ideas and I do not know what to do.

Does anyone have similar problem?

[Eric_t]

Hi,

I have read many times the errata files but I missed the following errata issue: 

PIM: Edge-sensitive mode of IRQ-pin may cause incorrect interrupt vector fetch

I use edge-sensitive mode of IRQ and all interrupts have the same priority. 

It seems that this is the cause of the fake interrupts & the unexpected reset.

I will make some test and I will keep inform the community.

Thank you

[Eric_t]

Hi, 

I am able to confirm that the problem with fake interrupts was due to silicon bug of "PIM: Edge-sensitive mode of IRQ-pin may cause incorrect interrupt vector fetch"

It has been almost a month and the problem does not occur any more.

Thank you

[lama]

If I were in your shoes I would implement following steps:

1) Excluding parts of the code in a logical order and  testing remaining code to localize error

2) Implement interrupt catcher. It means, there is subroutine for each interrupt created and all unused interrupt routines are directed to one function which can visualize the interrupt which was launched.

volatile unsigned int number_of_ISR = 0;

//==============================================================================

void Unimplemented_ISR(void)

{  asm nop; //insert breakpoint here. If you are here, check the "number_of_ISR"

   //asm BGND // you can use this code to enter the background debug mode

}

//==============================================================================

#pragma CODE_SEG NON_BANKED

interrupt    1      void ISR_1   (void) {number_of_ISR = 1; Unimplemented_ISR();}

interrupt    2      void ISR_2   (void) {number_of_ISR = 2; Unimplemented_ISR();}

interrupt    3      void ISR_3   (void) {number_of_ISR = 3; Unimplemented_ISR();}

…

// intentionally commented because it is used in application

//interrupt  20     void ISR_20  (void) {number_of_ISR = 20; Unimplemented_ISR();}

…

#pragma CODE_SEG DEFAULT

//==============================================================================

#pragma CODE_SEG NON_BANKED

interrupt 20 void SCI0_Isr(void)

{  

   …

}

#pragma CODE_SEG DEFAULT

//==============================================================================

3) Test/Check all interrupts to be sure interrupt flags are correctly cleared. Interrupt routine, which is currently executed, is not interruptible (except I-bit is cleared)

4) Check all register which are writable anytime in the SPECIAL mode, but which are write once in the NORMAL mode.

5) Fill the stack area with some pattern to be able to check whether you do not underflow it. You must do it on some condition externally launched to avoid the pattern is written after each reset. Of course, if the code clears entire stack after reset in some init function you should avoid it to be able to check content of the stack after accidental reset.
However, if you want only to check where SP points you can use FILL command in the prm file which fills the stack with some pattern and you can visualize the SP or content of the stack or check the stack and visualize the value.
(note; reading SP leads to asm code)

Best regards,

Ladislav

[Eric_t]

Hi Ladislav,

Finally we got some progress.

We have an unimplemented interrupt of TC2.
It is a bit strange because we never enable TC2 interrupt.

As you can see at the attached picture, the procedure window shows UnimplementedISR50 (in our case is TC2 interrupt), data window shows _TIE.C2I = 0 (TC2 interrupt disable), _TFLG1.C2F=0 (TC2 interrupt flag clear).

Since TC2 interrupt (_TIE.C2I) is disable, TC2 interrupt flag is clear (_TFLG1.C2F), TC2 should never fire interrupts.

I have attached a picture that shows the connections of PORT T.

Our design left PT2 pin unconnected, but firmware set it as output.

(PTT = 0x30; DDRT = 0xF6; RDRT = 0xFF;)

Any ideas why TC2 fires interrupt?

[lama]

Hi,

could you please provide me a project to be able to check entire setup? This issue is not know to me from HW point of view even I am working with the devices for more than decade.

If yo do not want to share it with public you can send it to me via support system. (here is the procedure explained How to submit a new question for NXP Support )

Please, insert into question and/or subject part Assign to Ladislav into Auto 16-bit box.

(One possible issue, PT2 is set to output compare (OC) mode and disconnected from pin logic and enabled. When OC event happens then interrupt is generated.)

Best regards,

Ladislav

[Eric_t]

Hi Ladislav,

Now we left interrupt vectors to default (we left IVBR to default), and now everything works properly.

I think that the problem remains, but for some reason it is now rarely occurs.

I have to find out why fake interrupts occurs when we move the interrupt vector table.

[Eric_t]

Hi Ladislav,

I just confirm that the issue still exists, so the position of interrupt vector is not the problem.

I have add a ticket  with subject: "Assign to Ladislav: Sometimes interrupts do not work after unexpected reset".

I have attached the project a brief description of the initialization of controller.

Thank you

[Eric_t]

Hi Ladislav,

At my previous post, I have said that, if we move interrupt (IVBR) to another location, some other Unimplemented interrupts fires.

This is wrong. Moving interrupt (IVBR) to another location, exactly the same Unimplemented interrupts fires ("TC2" and "COP reset").

Thank you

[Eric_t]

Hi Ladislav,

Our implementations sets interrupt at 0xF310 location (IVBR = 0xF3).

As you can see at the attached picture, UnimplementedISR54 (in our case COP watchdog reset) occurs.

Since "COP watchdog reset" is at fixed address, UnimplementedISR54 interrupt should never fires.

We have moved interrupt (IVBR) to another location and now some other Unimplemented interrupts fires. 

It seems that there is some kind of problem with interrupt vector.

Probably TC2 interrupt never fires, it is just some kind of problem of the interrupt vector table.

I want to attached a file with the interrupt vector and the configuration if controller but I do not know how to do it.

Best regards

[MJW]

Hello,

this situation does not sound like a real reset, but SW somehow executing the reset routine without a real HW reset occuring. If maskable interrupts are not working despite I-bit cleared, please check the state of the IPL bits (S12X only, in CCRW[10:8]) as well (IPL masks interrupts at lower or equal levels).

HTH,

MJW

[Eric_t]

Hi MLW

I will see what is the state of IPL, I just need some days until an unexpected reset occurs.