Program fleet if add sEI and CLI in case of protecting read&write process

[kimchan_eb]

Hi,

I have many interfaces, for example 

ebStatus = APP_InterruptDisable ();

*****read or write process****

APP_InterruptEnable(ebStatus);

to protect process when reading or writing.

Now I add "__asm SEI;" in APP_InterruptDisable () and "__asm CLI" in APP_InterruptEnable(ebStatus).

Then I power on the board and it can send and receive frames.

But, if I send a NM frame to ECU, it will cause program fleeting.

It's sure that __asm SEI and __asm CLI will have effect on this because it's all normal it I don't add them.

But I can't figure out why it will have effect on it.

So I want to know, why it has problem when add them in case of sending NM frame to ECU.

I have fleeting problem before in other case and I solved by enlarging stack size.

But it doesn't work here.

ECU: S12G128

Br,

Kim

[RadekS]

Hi Kim,

As you already mentioned, the stack overflow is one of the typical root causes for code runaway.

However, the most typical root cause is an unexpected interrupt.

This also correlates with your description about SEI and CLI instructions.

Please check which interrupts are enabled in your application and compare it with defined interrupt routines.

Optionally, please use G128-Interrupt_catcher-CW51 example code for your inspiration and define all interrupt vectors. With such code, you may detect a source of the unexpected interrupt.

The example code you may download at:

https://community.nxp.com/docs/DOC-93792

I hope it helps you

Have a great day,
Radek

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[kimchan_eb]

Hi Radek,

Thank you for your example code.

I tried and I found it fleet to 0xFFFF, not stopping at the Unimplemented_ISR().

Maybe I have to debug somewhere else.

Do you have any other suggestions?

Br,

Kim

[RadekS]

Hi Kim,

Did you implement all interrupts?

The PC=0xFFFF in CPU register window may happen by a jump to this address or by simple BDM disconnection. When the connection is lost, the hiwave debugger shows nonsense data - typically 0xFFFF.

Next idea: Unexpected reset. Please check reset line by the oscilloscope.

Additionally, please check also whether you defined all three reset vectors (this shouldn't have any influence, just for sure).

Next idea: Any problem with changing PPAGE. Do you edit this register manually in any of your ISRs?

By default, the PPAGE isn't stored and restored at enter/leave of ISRs.  You may try to add -CpPPAGE compiler option. It makes compiler saving restoring PPAGE register on entry and exit from interrupt handlers.

Next idea: Some problem with pointers... 

I hope it helps you

Have a great day,
Radek

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[kimchan_eb]

Hi Radek,

 I have known what caused the problem.

Before clear CAN rx flag, there is APP_InterruptDisable() and APP_InterruptEnable() in which customer implemented sEI and CLI. So when CLI was excuted, the CAN rx interrupt will be called agian. And it will be a loop and the program will fleet(maybe it's for stack size?)

If clear rx flag before CLI, it won't happen.

But it's only in normal case, not in high bus load. Problem still exists in high bus load case, and I'm still checking why.

Br,

Kim

[RadekS]

Hi Kim,

I am glad that you found a root cause.

I would like to recommend one of our application notes which may help you:

AN2554 Clearing and Disabling Interrupt Flags

http://www.nxp.com/files/microcontrollers/doc/app_note/AN2554.pdf

For high bus load, the establishing of input Rx filter may help you. I can recommend the tool for calculating CAN ID filter values at https://community.nxp.com/docs/DOC-335457

I hope it helps you

Have a great day,
Radek

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[kimchan_eb]

Hi Radek,

I implemented all interrupts except CAN related ones.

Thank you for other ideas, I will try these.

Br,

Kim