MPC5777C: wait instruction impact across cores

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MPC5777C: wait instruction impact across cores

786 Views
usmanimtiaz63
Contributor II

Hi,

I am working on MPC5777C and I have observed that when CPU1 is in wait state because of calling wait instruction; if CPU0 executes sync or syncm instruction it also stops. Can you please describe this behavior and is there any memory sync instruction which can avoid this behavior?

As per wait APU description;

pastedImage_2.png

and waiting state;

pastedImage_3.png

So ideally CPU0 should not wait for any handshaking with CPU1.

-----------------------------------------------------------------------------------------

Related: MPC5777C: does Decrementer interrupt exit wait APU? 

4 Replies

671 Views
rweiss
Contributor V

Hi,

please check the SIU_HLT1 register. The WAIT instruction can be configured to halt several peripherals, including both cores. If SIU_HLT[CORE0] is set, a WAIT instruction on core_1 would actually prevent the debugger from halting core_0.

If you are using WAIT, you have to make sure that there are any interrupts assigned (and actually occurring!) on that core. If not, then it will be stuck in WAIT and can never release any semaphores.

Best regards,

Reinhard

0 Kudos

671 Views
lukaszadrapa
NXP TechSupport
NXP TechSupport

Hi,

I did quick check on my board but I can't see such behavior on my side. Do you have some simple project to reproduce the problem?

Regards,

Lukas

0 Kudos

671 Views
usmanimtiaz63
Contributor II

Hi,

I am using MPC5777C Cobra55 and observed this behavior. This behavior did not occur on other MPC targets like MPC5748G.

My use case is that core 1 is in idle mode of OS and OS use wait instruction in idle mode. So, when the other core (core 0) locks a semaphore and updates a shared variable (MMU is also On as per your first comment on Questions about Cache in the MPC5777C ), it then call sync instruction and this sequence happen more than once on core 0 while core 1 is in idle.

In this scenario a situation comes when core 0 also get stuck and even Lauterbach debugger can not call break on core 0 unless a break is executed on core 1. However it works perfect if OS do not use wait in it's idle mode.

671 Views
lukaszadrapa
NXP TechSupport
NXP TechSupport

Hi,

I did a few more tests and I really can't see that on my side...

Regards,

Lukas

0 Kudos