M4 core interrupt behavior in i.mx7d.

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

M4 core interrupt behavior in i.mx7d.

ソリューションへジャンプ
1,275件の閲覧回数
hideo_yamashiro
Contributor III

Hello.

We are using m4 core in i.mx7d,
and we have an issue on RTOS like freeRTOS, exactly we use aother commercial RTOS.

The memory manage excepion or hard fault exception happen during running our program.
However, When we changed CAN/UART7 interrupt priority to lower than Systick interrupt priority,
The excptions do not happen.

So, We try to find the reson by reading the source of etnry to interrupt service routine and return from it.
Unfortunatly, We do not have enough knowlagements.

If you do not mind, Could you tell us the answers?

(1).When basepri=0x00, nested preempt interrupt can be used?

(2).When returning from interrut service routine, how is the privous state restored?
Especially, we do not know how interrupt priority is restored.

Ex.
We think about IRQ1(low) and IRQ2(high).
basepri=the priority of IRQ1(low)
(i).IRQ1 happen
save xPSR,LR,PC,r12,r3,r2,r1,r0 registers into stack.
change LR to EXC_RETURN and PC is entry for IRQ1 service routine.
(ii).IRQ2 happen ( now we do not think about tail chain. )
save xPSR,LR,PC,r12,r3,r2,r1,r0 registers into stack.
change LR to EXC_RETURN and PC is entry for IRQ2 service routine.
(iii).The IRQ2 Servcei routine finishs by "bx lr" instruction (lr=EXC_RETURN)
restore xPSR,LR,PC,r12,r3,r2,r1,r0.
and return to the state when IRQ1 service routine was running.
WHY M4 CORE CAN RETURN TO THE INTERRUPT PRIORITY TO IRQ1 SERVICE ROUTINE?
(iv).The IRQ1 Servcei routine finishs by "bx lr" instruction (lr=EXC_RETURN)
restore xPSR,LR,PC,r12,r3,r2,r1,r0.
and return to the prevous state before IRQ1 happens.
WHY M4 CORE CAN RETURN TO THE INTERRUPT PRIORITY TO THE STATE BEFORE IRQ1 HAPPEND?

(3).Is "basepri register" changed?
On the about situation.
Is "basepri register" changed at the time IRQ1, IRQ2 happen and return from IRQ1 and IRQ2 service routine?

Best regards,
Hideo Yamashiro.

0 件の賞賛
返信
1 解決策
1,195件の閲覧回数
hideo_yamashiro
Contributor III


Hello, Aldo.

Thank you for your reply.

I asked RTOS developer about the issue.
The RTOS developer showed an interrupt handing source code added 'isb instraction'.
The RTOS developer said that insert of isb instraction is not for the issue,
the insert is just recommended from someone ( maybe The RTOS developer got the information for a web side ).

And The RTOS developer also added 'dsb instruction' before interrupt return
( 'bx lr' with EXC_RETURN(like 0xFFFFFFF9)) to the source code for Arm Errata 838869.

The source code is working correctly. It have no problem.
But the RTOS developer said that they also could not find any mechanism why the issue happens.

I will ask ARM developer site about the issue.

Thank you.
Hideo Yamashiro.

元の投稿で解決策を見る

0 件の賞賛
返信
5 返答(返信)
1,274件の閲覧回数
hideo_yamashiro
Contributor III

hello.

 

I took a mistake.

"On the about situation." is not correct.

"On the above situation." is correct.

Best regards,

Hideo Yamashiro.

 

0 件の賞賛
返信
1,237件の閲覧回数
AldoG
NXP TechSupport
NXP TechSupport

Hello,

I have contacted internal team for this, please see below:

(1).When basepri=0x00, nested preempt interrupt can be used?

[Ty] I think it should be OK to use preempt interrupt when basepri=0x00.

(2).When returning from interrut service routine, how is the privous state restored?
[Ty] It depends on how your RTOS do this. Normally, the previous state should be restored from stack.

About your issue, do you know where the code raise the exception?

Normally, I would like to recommend adding more logs or using a debugger and IDE (e.g. jlink and IAR) to track such issue.

Best regards,
Aldo.

0 件の賞賛
返信
1,216件の閲覧回数
hideo_yamashiro
Contributor III

Hello, Aldo.

Thank you for your reply.
I'm sorry too late to reply.

Another CPU like SH7722(Renesas) has imask bits(interrupt priority) in status register.
But ARM m4 core does not have any bits to indicate current interrupt priority.
It just has a exception number(IPSR) in xPSR, does not have priority information directly.

So I was confused How ARM m4 core knows current priority when the core returns from nested preempt interrupt.

ARM m4 core store xPSR in stack when preempt interrupt happens.
And It restores xPSR register's value from stack when preempt interrupt returns.

So, I guess ARM m4 core lookups SHPR1/2/3 registers and IPR0/../123 in NVIC, to restor current priority.

This point maybe ok, I think.

 

I have a issue to happen memory manage fault or hard fault( perhaps escalation for usage fault ).
When I insert isb instraction after modifing basepri register, the issue does not happend.
When I remove isb instraction after modifing basepri register, the issue happens.

So, I guess the modification of basepri (like "msr basepri, r0") is not effective for a while.
I think the time is max 3 instraction execution time on M4 core.


I'm seraching the critcal section of RTOS which the issue happens.
But we do not find it.

We would like to know the reson why isb instruction is effective.

Best regards,
Hideo Yamashiro.

0 件の賞賛
返信
1,204件の閲覧回数
AldoG
NXP TechSupport
NXP TechSupport

Hello,

1. The interrupt priority is configured by IPRn registers.

  See:

https://developer.arm.com/documentation/100166/0001/Nested-Vectored-Interrupt-Controller/NVIC-progra...

  In our FreeRTOS, function __NVIC_SetPriority is used to set interrupt priorities.

  See CMSIS\Include\core_cm4.h.

2. For isb issue, I recommend customer to ask this on arm developer site, https://developer.arm.com/. As this seems to be a basic porting issue on arm core.

  For issues you have met on the new RTOS, the best way is asking for help from RTOS developer. It will be much easier if the RTOS developer can provide some examples that can run on arm core.

Best regards,
Aldo.

0 件の賞賛
返信
1,196件の閲覧回数
hideo_yamashiro
Contributor III


Hello, Aldo.

Thank you for your reply.

I asked RTOS developer about the issue.
The RTOS developer showed an interrupt handing source code added 'isb instraction'.
The RTOS developer said that insert of isb instraction is not for the issue,
the insert is just recommended from someone ( maybe The RTOS developer got the information for a web side ).

And The RTOS developer also added 'dsb instruction' before interrupt return
( 'bx lr' with EXC_RETURN(like 0xFFFFFFF9)) to the source code for Arm Errata 838869.

The source code is working correctly. It have no problem.
But the RTOS developer said that they also could not find any mechanism why the issue happens.

I will ask ARM developer site about the issue.

Thank you.
Hideo Yamashiro.

0 件の賞賛
返信