[参考译文] AM243X-AM243X：MCU-PLUS-SDK 上 M4 和 R5 内核之间的内核间通信设置 — 防火墙和时序限制问题

Petr,几个问题/评论:

• MPU 配置：请仔细检查您是否为两个内核 (R5F 和 M4F) 设置了一个共享区域、并且它是“非缓存“
• 我们使用 IpcNotify_syncall() API 来等待所有 CPU 准备就绪。 想知道您的项目中是否有类似的内容。 作为参考、IPC Notify API AM243x MCU+ SDK：用于 IPC Notify 的 API
• 如果您不能以我们的 IPC Notify 示例作为基准开始使用、该怎么办？  AM243x MCU+ SDK：IPC Notify Echo
  • 然后、您可以查看 MPU 区域的定义方式、这可能是内核同步的基准、并在准备好读取数据时相互通知（在共享存储器的情况下）

我正在与一位同事 ping 通、以了解有关带防火墙的内核间内存配置的更多意见。  

谢谢您、

Paula

 感谢 您发送编修。

小型集思广益 : 通常,当所有内核都运行时,IPC Notify 工作正常。 但是、在某些情况下、当在 M4 内核上运行的 MCU 域继续运行时、主域会经历复位。 由于这些域独立运行、这一刻会带来一个潜在问题：如果 M4 内核尝试访问由主域定义和管理的共享存储器、则可能会导致硬故障。

我看到了几种可能的方法来处理这种情况、但我不确定哪种方法最好。 对于您如何应对这一挑战的任何建议或示例、我将不胜感激。

1. 在每个 M4 请求之前等待 IPC 回波通知 : M4 可以等待来自 R5 内核的回显通知,然后再继续。 这种方法在理论上是可行的、但实际上无法使用、因为可能会引入不可接受的延迟。
2. 将通知重置为 M4 :实施一种机制,以便在 R5 内核发生复位时通知 M4 内核。 但是、如果器件在复位通知机制可以响应之前遇到严重故障、这可能不可靠。
3. 用于存储器访问的自定义错误处理程序 :  为 M4 访问某些内存区域时触发的异常开发自定义错误处理程序。 由于硬故障是由 Cortex M4 内核处理的、我不确定这样做是否可行、因此在这个级别实现此类处理程序的经验有限。

理想情况下、具有与 RAM 一样快的存储器类型、无论主域的复位或初始化状态如何、都能保持可访问状态、并且在被 M4 访问时不会产生硬故障。 这种解决办法是否存在？ 如果没有、是否有最佳实践或替代架构可以防止 M4 在访问该共享存储器时导致硬故障？

如有任何建议、建议或参考相关文档、将不胜感激！

或者是否可以分配共享存储器并在 M4 内核中对其进行保护？

Petr、如果您尚未观看、请观看 AM243x MCU+ SDK：使用 Spinlock 的 IPC 共享内存互斥量 演示。 本演示使用 MSRAM 存储器上的 reginon 作为 IPC 共享存储器。  

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 */


}