Other Parts Discussed in Thread: HALCOGEN
Hi,
Question about EMIF #4 and if writing through it is performed via DMA
Here is mentioned that MPU region for EMIF must exists and must be someting else than "normal" - this is clear
https://e2e.ti.com/support/microcontrollers/hercules/f/312/p/561396/2070063?tisearch=e2e-sitesearch&keymatch=emif%20MPU%20region%20type#2070063
But what happens when OS is thrown into mixture, I assume that first in case DMA is used that EMIF region in MPU must be all the time defined? This would be doable for example in SafeRTOS if/when you assign same task specific/configurable region to be used with same address & size & type & permission settings to all tasks (you can select region "freely" but must be same in every task).
But then let's see what SafeRTOS really does while it performs context switch
MOV R7, #0 /* Use R7 to disable region before reprogramming. */
LDMIA R0!, {R4-R6} /* Read 1st set of MPU registers */
MOV R1, #MPU_FIRST_TASK_REGION /* First task region */
MCR p15, #0, R1, C6, C2, #0 /* Set up region number */
MCR p15, #0, R7, C6, C1, #2 /* Disable region before programming */
MCR p15, #0, R4, C6, C1, #0 /* Set up base address */
MCR p15, #0, R5, C6, C1, #4 /* Set up access permissions */
MCR p15, #0, R6, C6, C1, #2 /* Set up size */
And that is performed for all user definable task regions. This is practically same what HalCoGen does in sys_mpu.asm EXCEPT there isn't that region disable since there is no context switches...
So this would result to a situation that while context switch is performed the DMA is running in the background but while DMA is running someone disables the region which is needed for EMIF#4 for a short period?
Haven't tested this but I assume that using OS (where you can't assign permanent regions which are not touched unless explicitly requested by application) & DMA for EMIF is no go solution? Wouldn't like to start testing this since there should be a academic answer for this (cannot ask this from SafeRTOS since this emif#4 is cpu specific issue, if this is no go like I think, then I could ask from OS supplier is there any potential way prevent certain regions to be modified (of course that 1 region write could be deleted from context switch code but manipulating source code is also prohibited).
It looks like also that xPortMPUConfigureGlobalRegion() does not help, since for tasks are reserved 8 configurable region, + 1 fixed for task stack == 9, left 3. And the left over 3 are fixed regions determined by OS 1) region for whole flash/used application flash area, 2) region for OS code, 3) region for OS RAM. That is total of 12 regions so no spare regions available since this device has according to HalCoGen only 12 regions?
There has been some threads in e2e about this but haven't seen directly that context switch related potential issue
e2e.ti.com/.../2070063
