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

cross mob
User19909
Level 3
Level 3
First like received
Hello, Its my first time to work with memory protection concept so excuse my questions if you see them intuitive.
1-Once memory protection is enabled this means that all memory is restricted unless i explicitly grant access to a memory region, correct?
2-Should the OS master core system application be granted access rights to all shared memory regions even on the other cores' MPU regions or its not relevant and each core should be the only core getting access to its regions
3-I am using TC37x which is a tricore architecture, I created 6 memory regions as a prototype and granted access to the whole memory address space,first 3 regions are for codes, in the core0 code mpu and gave access to core0 application protection sets, same goes to core1,cor2
second 3rd regions have the same whole address space but for data mpus, just to observe the mpu working, however it didn't I am just stuck at OS_Barrier.c it seems the OS is not happy with my configurations, but the MPU trap bit in DSTR is not raised. so it seems it is not a protection violation but rather something different, any insights?
4-What is the difference between Os system applications and OS applications

Thank you!
0 Likes
7 Replies
Darren_Galpin
Employee
Employee
First solution authored First like received
When you are talking about memory, are you talking about the PFlash attached to each CPU, or are you also talking about other memory areas?

Are any other traps set? Is there anything in the error registers in the XBAR?
0 Likes
User19909
Level 3
Level 3
First like received
For code MPUs I granted access to flash and psprs, is there a flash attached to each CPU? Isn't it one physical flash? .for data mpus i granted access to the whole address space starting from 0x00000000 to 0xFFFFFFFF, no traps are set in the DSTR, The XBAR has no errors as well.
0 Likes
Darren_Galpin
Employee
Employee
First solution authored First like received
TC3x devices there is a PFlash bank per CPU. The address space is contiguous for most devices, so it looks like there could be one flash, but they are in up to 3MB banks per PFlash.

For Data, you intend to use just DFlash? And are you just reading, or are you trying to write as well? Granting the whole address space for data doesn't sound correct (I'm not from the software side, so I'm not aware of the C files and the routines you refer to) - segment F is mostly register space, If there are no traps and errors it doesn't sound like it is trying to do an access at all.

Is there anything from software debug which says what command/statement it is hanging with?
0 Likes
User19909
Level 3
Level 3
First like received
Granting access for the whole address space is not the implementation ofcourse it is just a prototype i am trying to see the behaviour of the system when granting access and when restricting access and violating it, just a prototype you can say.
but if there is a pflash dedicated to every core, how would the error handling takes place if there is one SMU Alarm dedicated for all ECCs for the flash and the address in the SBAB/DBAB registers, to which core would the address in these registers point since these registers exist in the PFI and not in each core's registers?
0 Likes
Darren_Galpin
Employee
Employee
First solution authored First like received
There are a set of xBAB registers per PFlash bank, so each PFlash bank has it's own alarm, To access these registers you read to the appropriate base address offset for the PFlash bank you want to target, but with the same register offset.
0 Likes
User19909
Level 3
Level 3
First like received
aha, understood...what about the MPU , when a violation occurs, can you walk me through what exactly happens from there..from what I understand a Class 1 trap handler is invoked, however is there an SMU alarm related to the MPU? or to be precise, how does the OS know about an MPU violation and how the protection hook can be invoked.
0 Likes
Darren_Galpin
Employee
Employee
First solution authored First like received
The trap handler is invoked by the CPU - when it reads the data with the error, it generates a trap, and the exact type depends of the type of error (so local program fetch, bus fetch, ECC error or bus error - defined by the TIN). The CPU then jumps to a trap handler based on the class/TIN.

The SMU indicates to the CPU that it has an alarm either via a Non-Maskable Interrupt (aka NMI trap), or by the interrupt system. So I would assume that the CPU doesn't signal the SMU, as the SMU would then have to signal the CPU that it had received one to deal with it.
0 Likes