Does the S32DebugProbe not enter ISR any more if it ever stops at an breakpoint?

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

Does the S32DebugProbe not enter ISR any more if it ever stops at an breakpoint?

2,323件の閲覧回数
chengpei
Contributor III

Board: S32G-VNP-RDB2

SW version: S32 Design Studio 3.4.3, SW32G_RTD_4.4_3.0.2_HF01

Debugger: S32DebugProbe

Background: When we debugging the software of our controller, we found that the tasks stop schedulling, while the Systick and PendSV were both Pending but just can not enter the exception(if pause the program and step, it can enter the exception),

chengpei_0-1687232632068.png

In order to demonstrate this problem concisely, now I will use the nxp provided example(Can_example_S32G274A_M7) to reproduce this situation.

  1.   Create Project from example

chengpei_1-1687232632040.png

chengpei_2-1687232632100.png

  1.   Add the following two lines to the main function:

chengpei_3-1687232632132.png

  1.   Add a counter to PendSV_Handler:

chengpei_4-1687232632019.png

  1.   Generate the code and build the project:

chengpei_5-1687232632028.png

  1.   Start debugging,

chengpei_6-1687232632280.png

  1.   Now, if we click Resume directly, after a few seconds, click pause, we can see that the program stops in the while(1) loop in the PendSV_Handler, PendSV_CNT=1 as we want,

chengpei_7-1687232632194.png

chengpei_8-1687232632196.png

  1.   If we did not click Resume directly in step 6, and instead, add an breakpoint before triggers the PendSV. After this, click resume, the program will stop at the breakpoint

chengpei_9-1687232632355.png

chengpei_10-1687232632390.png

  1.   Click resume again, wait a few seconds, pause, we see the program stops at the next while(1) loop, and PendSV_CNT=0! It did not enter PendSV ever

chengpei_11-1687232632394.png

chengpei_12-1687232632411.png

now if we check ICSR, we can see the PendSV is pending(now if we click step, it can enter the PendSV exception),

chengpei_13-1687232632451.png

So, why does the debugger do not enter exceptions any more if it ever stop at an breakpoint?

タグ(2)
0 件の賞賛
返信
4 返答(返信)

2,306件の閲覧回数
Daniel-Aguirre
NXP TechSupport
NXP TechSupport

Hi,

Thanks for the detailed explanation. When the core is stopped under a debugging session, it cannot execute any other instruction until it is released again. For what you are explaining, the behavior is the expected.

We have used 2 EIRQ's and if we stop the executing core, even if we manually set both flags, it cannot execute the ISR until it is released or set to run.

Could be that we are misunderstanding your request, if so, we apologize.

Please, let us know.

0 件の賞賛
返信

2,298件の閲覧回数
chengpei
Contributor III

Dear Daniel Aguirre,

Thank you for your reply, I think there are some misunderstanding. Yeah, of course, I know it cannot executes the ISR when it was in stop state, what I mean is, even I resume the program, it cannot execute the ISR too. 

The situation is, I stopped at an breakpoint, the ISR was in pending state, and then I clicked resume, it ought to go to execute the ISR, but it wasn't.  

Could you please try as I discribed in the pdf? If convenient. 

Add the two lines of code(trigger PendSV, while(1);) to any provided examples which support ISR, add an breakpoint before the trigger, resume twice, you can reproduce the situation.

Thank you very much!

0 件の賞賛
返信

2,276件の閲覧回数
Daniel-Aguirre
NXP TechSupport
NXP TechSupport

Hi,

Thanks for the clarification. Still, we are not seeing the behavior you are describing.

We have added the line you have requested to our program and put a breakpoint prior to its execution, once we resume from the breakpoint and pause the program we see that the counter inside PendSV_Handler has the value 1:

DanielAguirre_0-1687373372061.png

DanielAguirre_1-1687373377154.png

Also, we have configured ISR's in our program. We can pause the program then resume and the ISR is executed, there is no additional steps on this.

Again, let us know if we are misunderstanding your request.

Please, let us know.

0 件の賞賛
返信

2,230件の閲覧回数
chengpei
Contributor III

Hi, 

Thank you for the test, maybe there's something wrong with my debugger, I'll take another look.