AM2634: MPU Settings

Hi Sue A,

This information is not enough to support this. Do you see the same behavior with IPC notify example or would you prefer blocking the access for this region via MPU settings of self core to eliminate the same core is not responsible for this behavior ?

Best Regards,
Aakash

hi Aakash,

I am unable to use IPC notify example as the system project there is configured for AM2631 instead of AM2634. Could you let me know what other details you need to help in this case?
Also, how to block access to a specific region via MPU settings of self core?

Thanks!

Hi Aakash,

Thanks for your response.
I found that the issue is with IpcNotify_syncAll function in below code. When I try to boot up the application from QSPI flash memory, it looks like the execution gets stuck in IpcNotify_syncAll. Can you tell me what might be causing this and how to resolve it?

when I comment out the IpcNotify_syncAll function, the application boots up fine.

Hi Sue A,

It looks like the memory is most likely used for IPC communication -

Let me try to get more information on IpcNotify_syncAll relation with this memory.

Best Regards,
Aakash

Thanks Aakash. I will wait for your response.
FYI, the variable SyncAllCores's address is 0x701D0000.

Hi Sue,

The address 0x701D0000 is not used for IPC. IPC uses the mailbox memory starting from 0x72000000.

IPC Sync All is used to synchronize between all cores in the application. The SysCfg module for IPC needs to be configured properly for each core in the system. 

How many cores are you using? Also, can you post a screenshot of the SysCfg module configuration for IPC in each core?

Regards,

Ashwin

Hi Ashwin,

Thanks for your response.
I am using 3 cores. Core 0, core 2 and core 3. 
Core 0 and core 1 are set up as lock step and core 2 and core 3 are in dual core mode.

Hi Ashwin,

Please let me know if you have any update.

Thanks!

Hi Sue,

The configuration looks fine. Can you add breakpoint at IPC Notify ISR IpcNotify_isr() and see if it gets invoked for each core after calling IpcNotify_syncAll ? When IpcNotify_syncAll  is invoked, the core sends a sync message to every other core and then wait for sync message to be received from all other cores. This helps to synchronize every core in the system. I'm suspecting that the ISR is not getting hit for a core in this case.

Regards,

Ashwin

Hi Ashwin,

When I run in NO BOOT mode debugging from CCS,
1) when I just hit run on "group" of cores (WITHOUT a breakpoint at IpcNotify_isr()), the application runs fine. The SyncAllCores is set to 0x0D. So I am sure IpcNotify_isr() is invoked for every core as expected.
2) When I hit run on "group" of cores (WITH a breakpoint at IpcNotify_isr()), Core 0 and Core 2 hit the breakpoint at the same time, after running again, Core 3 hits the breakpoint. However, SyncAllCores gets set to 0x09. It somehow seems like the bit written by Core 2 gets overwritten. Could you please advise me on why this might be happening and how to resolve it? FYI, I have freeRTOS running on Core 2 with dynamic memory allocation for task. The other two cores are baremetal. I am not sure if this has anything to do with memory overwriting.

Thanks for your help!

...

Hi Sue,

This issue seems to be because of read modify write that you are doing here. It can cause race condition since the action is not atomic. Once a read has been completed, another core may update the memory causing current core to have stale data. Since the memory is a shared resource across cores, we should use spinlock to protect it.

Another suggestion, if SyncAllCores is used just to synchronize every core, it can be replaced with IpcNotify_syncAll() since it does the same thing. IpcNotify_syncAll() can be called before and after the GPIO write.

Regards,

Ashwin

Hi Ashwin,

Thanks for the quick response.
I commented out SyncAllCores and made sure there is no shared resource between the cores.
I am only using IpcNotify_syncAll() to sync the cores now. Now when I apply breakpoint at IpcNotify_isr(), the behavior is similar to what I described in case 2 earlier (When I hit run on "group" of cores (WITH a breakpoint at IpcNotify_isr()), Core 0 and Core 2 hit the breakpoint at the same time, after running again, Core 3 hits the breakpoint). 

Core 0 and Core 3 start running fine but Core 2 enters into an infinite abort loop. The execution on Core 2 does not reach GPIO Write that is after IpcNotify_syncAll(). Please advice if I'm missing anything.

Hi Sue,

Does the above code work fine without breakpoints?

Also, can you step through the ISR in Core 3 and figure out where it goes into data abort?

Regards,

Ashwin

Hi Ashwin,

yes, the code works fine when I run it in NO BOOT mode from CCS without breakpoints. However, this code fails to boot up from QSPI flash memory.

When I add breakpoints while running in NO BOOT mode from CCS, Core 2 enters into infinite abort loop. Here is the code trace..

Sue,

Can you step through the IPC Notify ISR in Core 2 and figure out where it goes into data abort?

Regards,

Ashwin