MPC5748G Shared Memory SEMA42

[AhpKim]

Hi,

I want to make a project in that all three cores in MPC5748G share resources using semaphore. 

So I used the sema42_multicore example as a base and then put shared_mem.c, shared_fun.c from S32R274 multi-core shared memory.

And also followed the post from this forum too. Here's the link to it. 

https://community.nxp.com/t5/S32-Design-Studio/How-can-i-use-the-same-variables-in-different-sub-pro...

But it seems like none of the cores can access the shared memory.

1. when I compile the project, it gives me a compile error for using a core_z7_1_counter. 

If I take it out, then the project compiles normally. 

2. While Debugging in flash mode, the cores cannot access to the shared memory. It falls into loop somewhere. While debugging in ram mode, the cores can access to the shared memory. What is the difference between flash mode and ram mode? 

3. And while debugging in ram mode, the variables updates when other thread's suspended. I would like to know how to use sema42 properly so the variables updates while the other thread's running. 

I'll attach my project here, it's divided into 2 cause of the size. (unzip (2) and (3) and unzip project.z01 and project.zip together)

Thanks

[lukaszadrapa]

Hi @AhpKim 

we are currently overloaded due to summer vacations, so we have very limited possibilies to debug customers' code.
In short, "ram mode" is a mode when debugger loads everything to RAM only (including code). It's for quick debugging only when a project is small enough, so everything fits into RAM. Obviously, you can just reset the device to start over, it's necessary to load the project again to RAM by debugger.
"Flash mode" is normal mode when the project is loaded to flash, so it will work also after reset or power-on and also without debugger.
You can compare the linker files to see the difference.

If you have a problem like "It falls into loop somewhere" then I guess that machine check exception was triggered or something like that. I would double check the linker files (I can't see them because files from installation folder are used) and you can also check which address is accessed exactly - if it is really the shared memory segment. You can simply step asm code and check which address is used. This could move you forward.

Regards,
Lukas

[AhpKim]

Hi,

Thanks for the reply! I can wait till others come back from vacations. Until then I'll try my best to fix this problem, but I might ask more questions later thou...

I'll check the linker files, but I'm not sure how to check which address is accessed exactly. Should I put breakpoints on the assembly codes?

Thanks,
AhpKim