MCU-PLUS-SDK-AM243X: Inter-core Communication Setup Between M4 and R5 Cores on AM2434 - Firewall and Timing limitation Issues

Petr, few questions/comments:

• MPU configuration: please double check you have setup a shared region for both cores (R5F and M4F) and it is "Non Cached"
• We use IpcNotify_syncAll() API to wait for all the CPUs to be ready. Wondering if you have something similar in your project. For your reference IPC Notify APIS AM243x MCU+ SDK: APIs for IPC Notify
• If you haven't maybe good to start with our IPC Notify example as a baseline? AM243x MCU+ SDK: IPC Notify Echo
  • From there you can take a look on how MPU regions are defined, and it could be a baseline for how cores sync, and inform each other when data is ready to be read (in case of shared memory)

I am pinging a colleague, for additional comments on intercore memory configuration with firewalls. 

Thank you,

Paula

 Paula Carrillo, thanks for your comments.

Small brainstorming: Generally, IPC Notify works well when all cores are operational. However, there are scenarios where the MAIN domain undergoes a reset while the MCU domain, running on the M4 core, continues operating. Since these domains operate independently, this moment presents a potential issue: if the M4 core attempts to access shared memory that is defined and managed by the MAIN domain, it can result in a hard fault.

I see a few possible approaches to handle this situation, but I'm unsure which is best. I’d appreciate any recommendations or examples of how you've tackled this challenge.

1. Wait for IPC Echo Notification Before Each M4 Request: M4 could wait for an echo notification from the R5 core before proceeding. This approach is theorical viable but practically can't be used because may introduce unacceptable latency.
2. Reset Notification to M4: Implement a mechanism so the M4 core is notified if the R5 core undergoes a reset. However, this may not be reliable if the device encounters a critical failure before the reset notification mechanism can respond.
3. Custom Error Handler for Memory Access: Develop a custom error handler for exceptions triggered when the M4 accesses certain memory regions. I’m unsure if this is feasible since hard faults are handled by the Cortex M4 core, and I have limited experience implementing such handlers at this level.

Ideally, there would be a type of memory as fast as RAM that remains accessible and does not generate a hard fault when accessed by the M4, regardless of the MAIN domain’s reset or initialization state. Does such a solution exist? If not, are there best practices or alternative architectures that could prevent the M4 from causing a hard fault when accessing this shared memory?

Any advice, suggestions, or references to relevant documentation would be greatly appreciated!

Or is there possibility to allocate share memory and protect it in the M4 core?

Petr, if you haven't, please take a look at AM243x MCU+ SDK: IPC Shared Memory Mutex using Spinlock demo. This demo uses a reginon on MSRAM memory for IPC share memory. 

volatile uint32_t gUserSharedMem __attribute__((aligned(128), section(".bss.user_shared_mem")));

    .bss.user_shared_mem (NOLOAD) : {
    } > USER_SHM_MEM    
}


MEMORY
{
    R5F_VECS   : ORIGIN = 0x0 , LENGTH = 0x40 
    R5F_TCMA   : ORIGIN = 0x40 , LENGTH = 0x7FC0 
    R5F_TCMB0   : ORIGIN = 0x41010000 , LENGTH = 0x8000 
    NON_CACHE_MEM   : ORIGIN = 0x70060000 , LENGTH = 0x8000 
    MSRAM   : ORIGIN = 0x70080000 , LENGTH = 0x40000 
    USER_SHM_MEM   : ORIGIN = 0x701D0000 , LENGTH = 0x180 
    LOG_SHM_MEM   : ORIGIN = 0x701D0180 , LENGTH = 0x3E80 
    RTOS_NORTOS_IPC_SHM_MEM   : ORIGIN = 0x701D4000 , LENGTH = 0xC000 
    FLASH   : ORIGIN = 0x60100000 , LENGTH = 0x80000 

    /* For memory Regions not defined in this core but shared by other cores with the current core */


}