Debug IPCF on 2 M7 cores

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

Debug IPCF on 2 M7 cores

932件の閲覧回数
Markus_Schroeder
Contributor II

Hello,

Currently, I try to get the IPCF communication to work between 2 M7 cores on the S32G274A.

All your examples are based on a communication between one A53 core running Linux with either one or two M7 cores running bare metal (probably with freeRTOS as well with few modifications).

For keeping it simpler, I want to start only with the M7 cores (most of the peripherals are already used by one M7 core, it would be too complex bringing in an A53 at this stage of the project, this will happen later).

From my understanding, it should be simple to modify the Example just for a communication between 2 M7 cores.

My question is, how can I debug this setup?

I have an S32 Debug Probe, I know how to debug single-core projects.

The example projects requires to load the M7 binaries via U-Boot.

Is there also a way to load the code for both cores via the S32 Debug Probe and then debug this combination? Can I debug two cores at the same time? Can I set breakpoints on both cores? When I stop one core, does the other one stop as well?

Sorry for the amount of questions. Maybe there is a documentation on this topic, I just couldn't find yet, then I would be glad if you can give me the link to that.

Best regards,
Markus

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

912件の閲覧回数
Daniel-Aguirre
NXP TechSupport
NXP TechSupport

Hi,

For multicore debugging, we can recommend looking into the following thread:

Solved: How to debug IPCF multi-core projects by using S32... - NXP Community

It may provide useful information on how to start a multicore debugging session.

As for your questions:

  • Is there also a way to load the code for both cores via the S32 Debug Probe and then debug this combination?
    • Yes, the provided thread may provide information on this regard.
  • Can I debug two cores at the same time?
    • Yes
  • Can I set breakpoints on both cores?
    • Yes
  • When I stop one core, does the other one stop as well?
    • It depends, but we understand that you are only able to stop one core at a time, not both at the same time.

Please, let us know.

0 件の賞賛
返信

887件の閲覧回数
Markus_Schroeder
Contributor II

Hi Daniel,

Thanks, that thread helped a lot. Multicore debugging is working now.

It seems fine, to let one core run and stop the other one.
In general things are working as expected.

I used the IPCF_Example_multi_instance_S32G274 example with both projects (one for M7_0 and one for M7_1), with slight modifications I could use the M7_0 project as sender and keep the other one as receiver.

Now I am working on the next step, I want to use the sender (M7_0) together with freeRTOS instead of the default bare metal setup. So far, the changes where quite simple, it seems to work.
I still leave the receiver side (M7_1) as bare metal project.

Only later in the example, after the M7_1 received already one message on the unmanaged channel, and the sender sends the first message on the managed channel, I get some problem during debugging.

When I run into a breakpoint, suddenly there is no more callstack, or at least there is something wrong:

Markus_Schroeder_0-1696591538945.png

It also doesn't show me, where it stops in the code. But it seems stopped.

Then, when I click run, I get this message:

Markus_Schroeder_1-1696591661174.png

Can you please help me with this issue? How can I avoid that?

Best regards,
Markus

 

0 件の賞賛
返信

883件の閲覧回数
Markus_Schroeder
Contributor II

I have one remark to my last issue:

This happens only during special circumstances, probably caused by placing the breakpoint at an unfortunately wrong location.

When I changed my breakpoint placing, it seems to work.

0 件の賞賛
返信

879件の閲覧回数
Daniel-Aguirre
NXP TechSupport
NXP TechSupport

Hi,

Could be that the debugger is trying to access parts of the memory that it is not available. It has happened before on our setups.

Through changing or initializing certain memory segments we were able to not have this behavior. It seems that the situation might be similar in your case.

One recommendation can be to compile the examples without optimization, just to confirm if the problem is with the debugger or with the debug session.

Please, let us know.

0 件の賞賛
返信