您好！
有关 EMIF 4的问题以及是否通过 DMA 执行写入
这里提到 EMIF 的 MPU 区域必须存在并且必须与"正常"不同、这一点很清楚
https://e2e.ti.com/support/microcontrollers/hercules/f/312/p/561396/2070063?tisearch=e2e-sitesearch&keymatch=emif%20MPU%20region%20type#2070063
但是、当 OS 被抛出混合物时会发生什么情况、我假设在使用 DMA 的情况下、必须始终定义 MPU 中的 EMIF 区域？ 例如、在 SafeRTOS 中、如果/当您将相同的任务特定/可配置区域分配给所有任务时、将使用相同的地址、大小、类型和权限设置(您可以"自由"选择区域、但每个任务必须相同)、则可以执行此操作。
但是、让我们看看 SafeRTOS 在执行上下文切换时的实际作用
MOV R7、#0 /*在重新编程之前使用 R7禁用区域。 *
LDMIA R0！、｛R4-R6｝ /*读取第一组 MPU 寄存器*/
MOV R1、#MPU_FIRST_TASK_REGION /*第一个任务区*/
MCR P15、#0、R1、C6、C2、 #0 /*设置地区编号*/
MCR P15、#0、R7、C6、C1、 #2 /*编程前禁用区域*/
MCR P15、#0、R4、C6、C1、 #0 /*设置基地址*/
MCR P15、#0、R5、C6、C1、 #4 /*设置访问权限*/
MCR P15、#0、R6、C6、C1、 2 /* 设置大小*/
这是针对所有用户可定义的任务区域执行的。 这实际上与 HalCoGen 在 sys_MPU.asm 中所做的一样、只是由于没有上下文切换、没有禁用该区域...
因此、这会导致执行上下文切换时 DMA 在后台运行、但在 DMA 运行时、有人会禁用 EMIF#4需要的短期区域？
尚未对此进行测试、但我假设使用操作系统(除非应用明确要求、否则无法分配未触及的永久区域)和 EMIF 的 DMA 是不可行的解决方案？ 不想开始测试这个、因为应该有一个学术答案(不能从 SAFERTOS 中询问这个问题、因为这个 EMIF#4是 CPU 特有的问题、如果这不是我想的、 然后、我可以向操作系统供应商询问是否有任何可能的方法阻止修改某些区域(当然、可以从上下文切换代码中删除1个区域写入、但也禁止操作源代码)。
xPortMPUConfigureGlobalRegion()看起来也不起作用，因为对于任务，保留了8个可配置区域，+ 1个固定用于任务堆栈=9，左3。 左侧的3是由操作系统确定的固定区域1)整个闪存/使用的应用闪存区域、 2)操作系统代码区域、3)操作系统 RAM 区域。 总共有12个区域、因此没有可用的备用区域、因为该器件仅根据 HalCoGen 提供12个区域？
e2e 中已经有一些有关这方面的主题、但没有直接看到上下文切换相关的潜在问题
e2e.ti.com/.../2070063
