TC299 MPU Initialization

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
eric_cal
Level 1
Level 1
5 replies posted 5 sign-ins First solution authored

Trying to initialize the MPU on an AURIX TC299B using Infineon's GitHub example for TC297 (https://github.com/Infineon/AURIX_code_examples/tree/master/code_examples/MPU_Memory_Protection_1_KI... as a base. I've been able to get to where the unit reboots due to watchdog violations but the example states that such resets shouldn't happen.

The end goal is to protect Core 0's memory from Core 1 read/writes and be able to customize the response when a violation occurs.

0 Likes
1 Solution
Prudhvi_E
Moderator
Moderator
Moderator
250 replies posted 100 solutions authored 25 likes received

Hello,

The Watchdogs are disabled at the beginning of the Core0_main function itself as shown below:

                                                 Prudhvi_0-1654577938912.png

Please check if you've enabled further after MPU Init or check if the Reset is because of the Trap handling code as a consequence of MPU violation.

In addition to that, if you want to protect Core - 0 memory from Core - 1 execution, please initialize and enable the MPU for Core - 1 as well. While initializing, ensure that Core - 0 memory is not given the access (Read or write or both) by basically limiting the region Core - 1 can Read from or Write to.

Regards,

Prudhvi.

View solution in original post

7 Replies
Prudhvi_E
Moderator
Moderator
Moderator
250 replies posted 100 solutions authored 25 likes received

Hello,

The Watchdogs are disabled at the beginning of the Core0_main function itself as shown below:

                                                 Prudhvi_0-1654577938912.png

Please check if you've enabled further after MPU Init or check if the Reset is because of the Trap handling code as a consequence of MPU violation.

In addition to that, if you want to protect Core - 0 memory from Core - 1 execution, please initialize and enable the MPU for Core - 1 as well. While initializing, ensure that Core - 0 memory is not given the access (Read or write or both) by basically limiting the region Core - 1 can Read from or Write to.

Regards,

Prudhvi.

eric_cal
Level 1
Level 1
5 replies posted 5 sign-ins First solution authored

Thanks, Prudhvi.

Found the source of the watchdog trip and have sorted that out.

Regarding protecting Core - 0 from Core -1 via initializing the MPU on Core - 1, can the same register references be used on Core - 1? Infineon's GitHub example uses references that are non-core-specific (e.g. CPU_DPR0_L) which would suggest each core could internally use such references separately and independently.

Additionally, is there a way to make the Protection Register Set value constant between function calls? From the documentation and tests it appears that the selected memory bounds are highly function/context dependent.

0 Likes
Prudhvi_E
Moderator
Moderator
Moderator
250 replies posted 100 solutions authored 25 likes received

Hello,

Yes the same reference could be used as the registers are updated based on the Core the program is running. Therefore, you should consider initializing those registers in CoreX_main.c (X represents core for the core you would like to configure).

The PRS value would remain constant unless the SW program changes it or during the Trap Handling. Please configure for your use case and see if it is changing. The change in the PRS value might be because of the Reset/Trap that you observed previously.

Regards,

Prudhvi.

According to the Architecture Manual for TC1.6P (9.3.2) "one of the sets is the current protection register set which determines the legality of memory accesses by the current task or ISR".

I've found that depending on where I attempt the illegal memory access (in terms of calling the function) the result is different. For example, if I call the violating function in the main loop right after the mpu_init function the violation is not detected. Instead the violating function appears to be required to be called at the end of mpu_init (i.e. within the init function itself).

0 Likes
Prudhvi_E
Moderator
Moderator
Moderator
250 replies posted 100 solutions authored 25 likes received

Hello,

You should call the violating function after the Memory Protection is enabled.

                             Prudhvi_0-1654702409206.png

Also, please take care of synchronization among the cores. The iLLD functions IfxCpu_emitEvent and IfxCpu_waitEvent ensures all cores reached certain sync point and only then Core - 0 proceeds further.

Please check if such approach is needed in your case because you may be executing a piece of code like LED Init etc from Core - 0 while the MPU Register Initialization in Core - 1.

Regards,

Prudhvi.

0 Likes

Prudhvi,

Thanks for the suggestions. I've ensured that the violating function is being called after the MPU is enabled and all calls are being performed on Core 0 (though the issue persists). However each core is running asynchronously (the exception is startup where Core 0 is ensured to start/init first). 

0 Likes
Prudhvi_E
Moderator
Moderator
Moderator
250 replies posted 100 solutions authored 25 likes received

Hello,

Regarding the highlighted statement below:

Prudhvi_0-1654748037290.png

As you're using the iLLD the program runs in single context. But if we have an OS integrated with multiple Tasks & ISRs then the PRS would change because in Safety system where Memory Protection is enabled each Task/ISR may have its own stack and its own access restrictions.

Either PRS would be changed if entire Memory Protection can be managed with 4 sets or the addresses in the DPR registers would be changed for each Task/ISR keeping the PRS constant.

Regards,

Prudhvi. 

 

0 Likes