Aurix TC3xx MPU protection – any specific handling for Segment 10 (0xAxxx.xxxx addresses, e.g. PFLASH)?

[ThNo]

Hello,

Got a question regarding the Aurix MPU protection / access to flash...

Scenario:
Range based memory protection is enabled.
Access to flash on non-cached address’ (0xAxxx_xxxx) and cached address alias (0x8xxx_xxxx).
Effective address’  fall outside of all defined ranges (DPRx_L/U, CPRy_L/U)

Observation:

• Access to 0x8xxx_xxxx causes Protection Trap   (as expected)
• Read-Access to 0xAxxx_xxxx   passes                      (expected:  Protection Trap)
• Write-Access to 0xAxxx_xxxx  causes BusError   (expected:  Protection Trap)

Question:
Is there anything specific for segment 10 wrt. to memory protection (e.g. any implicit access)?

Additional note:
Issue was reproduced with a TC375 and a TC397 with Lauterbach debugger.


Best regards,
ThNo

[Di_W]

HI ThNo,

Please refer to chapter 6.5.4.2.1 PFLASH Write Protection in AURIXTC3XX_um_part1_v2.0.pdf

A range of Flash can be write protected by several means that are all configured in the UCBs.

dw

[ThNo]

Hi dw,

thanks for the reply.
Sure there are additional means to protect the flash against any change of contents, but shouldn't the Memory Protection System of the TriCore be the first level of protection, or?

From the general description of the MPU

“10.3 Using the Range Based Memory Protection System” in TriCore_TC162P_core_architecture_volume_1_of_2  
…

For load/store:
“When an address is found to fall outside of all of the selected ranges then permission for the access is denied.”

=> So any read/write access (even in the 0xAxxx_xxxx address range) with an address which is not within a valid DPRx range, should always result in a Protection Trap, or?

For a given 0xAaaa_aaaa: 

• 0xAaaa_aaaa  is a valid address in PFLASH with correctly programmed content

BUT 

• range based memory protection is enabled and 0xAaaa_aaaa  is NOT contained within any DPRx range.

Observation:

• On READ access to 0xAaaa_aaaa, the data is returned     
  (expectation: denial of access by MPU -> Protection Trap)
• On (attempt to) perform WRITE access  results in a BusError.
  => The WRITE seems to have passed the MPU checking as the BusError is returned from interconnect/target?
  (expectation: denial of access by MPU -> Protection Trap)

Best regards,
ThNo

[Di_W]

Hi ThNo,

The protection registers protect the whole address space. The granularity of the protection ranges is 8 bytes for data and 32bytes for code.

If you enabled range memory protection, and access un-protected range, it will still be limited by PFLASH or NVM machanism. Please refer to 6 Non Volatile Memory (NVM) Subsystem in TC3xx User Manual.

dw

[ThNo]

Hi dw,

If the protection registers protect the whole address space (without any address exceptions), why an access to the flash on 0xAxxx_xxxx w/o having a valid region defined is not causing a Protection exception?


There are two different mechanisms:

1. 6 Non Volatile Memory (NVM) Subsystem in TC3xx User Manual 
   specifies measures to restrict access to flash on low(est) level.  Restrictions are applied on flash/sector basis and should be independent of the access via non-cached (0xAxxx_xxxx) or cached (0x8xxx_xxxx) addresses. 
   Violation should be signaled via  "Class 4 — System Bus and Peripheral Errors" traps
2. TriCore TC1.6.2 core architecture manual volume 1 (of 2)  “10 Memory Protection System”, “10.2 Range Based Memory Protection”
   specify the memory protection system implemented in the TriCore.
   Violation should be signaled via "Class 1 — Internal Protection Traps"

Basically (1) and (2) should be independent and implementing measures on different levels (on CPU core level and on flash/system level), or?

If (2) implements specific handling based on the address (e.g. if the Memory Protection System would “exclude” NVM addresses on 0xAxxx_xxxxx from checks)  
could you please provide explicit link/reference to documentation on the TriCore Memory Protection System?

Actual issue on TriCore Memory Protection System (excluding any specific protection with (1)):
In a scenario with

• Range based memory protection is setup / enabled.
• Address X is not contained within any valid/enabled protection range (defined by DPRx_L/U registers).

Expectation:
A data read/write access to X should always cause a Protection exception (Class 1 — Internal Protection Traps).

This should be independent if X is with the 0x8xxx_xxxx (cached flash access) or 0xAxxx_xxxx (non-cached flash access).
Could you please confirm/comment this expectation?

Issue/actual observation:
If address X is within 0xAxxx_xxxx,  the Memory Protection System seems to be bypassed, ie. neither a read nor a write access is causing a Protection exception:
- read returns the data  (when flash has valid data/no ECC error, …)
- on write,  a BusError is generated.  This is a result of a target response and not the TriCore cpu core / Memory Protection System.

Question:
Is this anywhere specified/expected behavior?
If so, where is this address dependency of the Memory Protection System is specified?
Are there any SFRs which could cause the observed behavior?

Best regards,
ThNo

[Di_W]

Hi ThNo,

If you use MPU protection, could you please give a code to show the protection exception?

Do you mean MPU doesn't work on 0xA--- ----?

I will help to  have a look at this.

dw

[ThNo]

Hi dw,

yes, it looks as the MPU wouldn't work for 0xA--- ---- / addresses 0xA--- ---- would just bypass without MPU check.

Can't provide simple source code, as I'm using an AUTOSAR OS for testing.
A register dump (TC375TP) is attached in reg_dump.zip:
- _reg_dump_prior_to_access_relevant.lst    (extracted - from my point of view - relevant registers for MPU; full set, see next)
- _reg_dump_prior_to_access_full.lst  (all registers)

Dump is taken prior to the data read/write access to 0xA030_0000 by CPU0. Read/write is performed via ld.w / st.w instructions.
Although neither a DPRx_L/H nor a CPRx_L/H contains a region for 0xAxxx xxxx, the read succeeds (flash has valid content) and the write  results in a BusError (not a Protection exception).

Best regards,
ThNo

[Di_W]

Hi ThNo,

Could you please write a sample code to access  0xA030_0000?

If you use OS, then you can use the sample code before the OS startup.

dw

[ThNo · Accepted solution]

Hi dw,

Seems we found the issue.
The observed behavior seems to be caused by use of debug mode and specific handling for memory addressed by the Debug Context Pointer Register (DCX).

See TriCore TC1.6.2 core architecture manual:

12.4.5 Breakpoint Trap
.
Emulator Space
To enable the debug monitor to operate without requiring the modification of the current memory protection settings, the following protection modifications are applied in debug mode:
...

• The 16 MByte region containing the DCX pointer (Base Address == {DCX[31:24],24’h000000}] will have MPR and MPW traps disabled for load and store operations in debug mode.

These two memory regions are referred to as emulator space. This behaviour may be unconditionally disabled by setting the Emulator Space Disable bit in the SYSCON register (SYSCON.ESDIS).

With the

• SYSCON.ESDIS = 0 (default value, ie.  emulator space is enabled).
  and 
• Debug Context Save Area Pointer (DCX) 
  having values  0xA000_04x0  (x depending on core)

basically all memory access in the range 0xA000_0000 .. 0xA0FF_FFFF would be performed during debugging w/o MPU checks.

Resolution:
In order to generate Protection exception during debugging,  the emulator space shall be disabled by setting SYSCON.ESDIS.
This needs to be applied on all cores.

If this change is applied,  a Protection exception was generated on read/write access to 0xA0xx_xxxx  as expected.

Thanx for the support.

Best regards,
ThNo