2391439_en-US

[#1]

S32K328: CM7_0 access to CM7_2 DTCM backdoor causes imprecise BusFault

Hello NXP team,

We are using S32K328 with RTD 7.x.

Software setup:

- CM7_0 runs a bootloader.

- CM7_1 is used by a second application.

- CM7_2 is not intended to execute application code.

- We are evaluating whether CM7_0 can use CM7_2 DTCM as system memory through the TCM backdoor/AHBS path.

Reference Manual context:

Chapter “Memory Map” says ITCM/DTCM can be accessed through the 32-bit AHBS interface by other masters, including other Cortex-M7 cores and eDMA.

The “TCM as system memory” section says an enabled core can use TCM of a disabled/waiting core after:

1. Enabling the target core TCM controller clock:

   MC_ME PRTN2_COFB2_CLKEN[REQ64] for Cortex-M7_2

2. Setting target core CPUWAIT:

   DCM_GPR DCMRWF4[CM7_2_CPUWAIT]

3. Enabling target core clock/access path:

   MC_ME PRTN0_CORE4_PCONF[CCE]

What we tried:

1. Set DCM_GPR DCMRWF4[CM7_2_CPUWAIT].

2. Set MC_ME PRTN2_COFB2_CLKEN[REQ64].

3. Set MC_ME PRTN2_PUPD[PCUD].

4. Applied MC_ME CTL_KEY sequence.

5. Waited for PRTN2_PUPD[PCUD] to clear.

6. Read PRTN2_COFB2_STAT and observed bit0/BLOCK64 active.

7. Set MC_ME PRTN0_CORE4_PCONF[CCE].

8. Set MC_ME PRTN0_CORE4_PUPD[CCUPD].

9. Applied MC_ME CTL_KEY sequence.

10. Waited for PRTN0_CORE4_STAT[CCS] to become 1.

11. Disabled MPU temporarily for the experiment.

12. Tried a single 32-bit write to the CM7_2 DTCM backdoor address.

Observed result:

- PRTN2_COFB2_STAT indicates the TCM controller clock request is active.

- PRTN0_CORE4_STAT[CCS] becomes 1.

- The first 32-bit write to the CM7_2 DTCM backdoor region causes an imprecise BusFault escalated to HardFault.

Questions:

1. For S32K328, what is the correct CM7_2 DTCM backdoor/system address range accessible from CM7_0?

2. Is CM7_2 DTCM backdoor access from CM7_0 supported while CM7_2 remains in CPUWAIT?

3. Besides MC_ME and DCM_GPR setup, is any XRDC configuration required to allow CM7_0 to write to CM7_2 DTCM backdoor?

4. Is any MPU region required even if MPU is temporarily disabled for the test?

5. Is any MSCM/MCM/XBIC/ENEDC setting required before using the TCM backdoor path?

6. Is PRTN2_COFB2_STAT[BLOCK64] the correct status bit to confirm CM7_2 TCM controller clock is active?

7. Is PRTN0_CORE4_STAT[CCS] the correct status bit to confirm CM7_2 clock/access path is active?

8. For DTCM ECC initialization through backdoor access, is a 32-bit write from CM7_0 sufficient?

9. If the first backdoor write causes an imprecise BusFault, which fault/XRDC registers should be checked to identify whether the failure is due to XRDC, interconnect, or unmapped address?

Current goal:

We only want to validate a minimal smoke test:

- one 32-bit write to CM7_2 DTCM backdoor,

- then readback,

- before considering any production use.

Thank you.

Re: S32K328: CM7_0 access to CM7_2 DTCM backdoor causes imprecise BusFault

Hello @krishna_Bugudi,

1.

Refer to the S32K3xx_memory_map.xlsx, DTCM_2 backdoor at 0x21800000

2.

Yes

3.

No

4.

No

5.

No

6.

Yes, refer to RM, Section 3.4 TCM as system memory

7.

Yes

8.

Yes, refer to RM, Table 102. Memory ECC initialization summary

9.

You wrote that XRDC is disabled. So, it won't be reported by XRDC. 

What address do you write?

Regards,

Daniel

Re: S32K328: CM7_0 access to CM7_2 DTCM backdoor causes imprecise BusFault

Hello Daniel,

Thank you for the confirmation.

We updated the test to follow the RM/NXP sequence exactly and are still seeing the store hang.

Confirmed address:

We are writing to:

0x21800000

This matches S32K3xx_memory_map.xlsx:

DTCM_2 Backdoor:

- Start address: 0x21800000

- End address:   0x2181FFFF

- S32K328 implemented size: 128 KB

The memory map also shows PRAM2_TCM_XBIC is present on S32K328 at:

0x40408000 - 0x4040BFFF

and describes it as:

"Crossbar Integrity Checker (PRAM2 & TCM backdoor AHB Splitter"

while TCM_XBIC at 0x40400000 is marked Reserved for S32K328.

Latest test sequence:

1. Set MC_ME PRTN2_COFB2_CLKEN[REQ64].

2. Set MC_ME PRTN2_PUPD[PCUD].

3. Apply MC_ME CTL_KEY sequence.

4. Wait for PRTN2_PUPD[PCUD] to clear.

5. Read PRTN2_COFB2_STAT.

Observed:

PRTN2_COFB2_STAT = 0x00000039

6. Set DCM_GPR DCMRWF4[CM7_2_CPUWAIT].

   Readback confirms:

   DCMRWF4 = 0x00080000

7. Set MC_ME PRTN0_CORE4_ADDR to a safe loop address.

   Readback:

   PRTN0_CORE4_ADDR = 0x00402408

8. Set MC_ME PRTN0_CORE4_PCONF[CCE].

9. Set MC_ME PRTN0_CORE4_PUPD[CCUPD].

10. Apply MC_ME CTL_KEY sequence.

11. Wait for PRTN0_CORE4_STAT[CCS] to become 1.

Observed:

PRTN0_CORE4_STAT = 0x00000001

12. Disable CM7_0 MPU temporarily for isolation.

   MPU_CTRL before disable = 0x00000003

13. Attempt one single 32-bit write:

   *(volatile uint32_t *)0x21800000 = 0u;

Latest breadcrumb log:

[CORE2_DTCM_SMOKE] S4B: WORD0 WRITE START addr=0x21800000

The next breadcrumb after the store is not reached:

[CORE2_DTCM_SMOKE] S4B1: WORD0 STORE ISSUED BEFORE DSB

So the store itself appears to stall or not complete before reaching the following instruction. The DSB is not reached in this latest test.

Question:

Since you confirmed that:

- 0x21800000 is the correct DTCM_2 Backdoor address,

- CM7_0 access is supported while CM7_2 is in CPUWAIT,

- no additional XRDC/MPU/MSCM/MCM/XBIC/ENEDC setup is required,

- PRTN2_COFB2_STAT[BLOCK64] is the correct status bit,

- PRTN0_CORE4_STAT[CCS] is the correct status bit,

- 32-bit writes are valid for DTCM ECC initialization,

what could cause the first 32-bit store to 0x21800000 to stall before completion?

Should we inspect PRAM2_TCM_XBIC at 0x40408000 for TCM backdoor AHB splitter errors on S32K328?

If yes, could you please point us to:

1. The PRAM2_TCM_XBIC status/error registers to read.

2. The expected error indication for a failed DTCM_2 backdoor transaction.

3. Whether any error-clear sequence is required before retrying the access.

4. Any other MC_ME/DCM/MSCM/XBIC/fault registers that should be captured when the store does not complete.

Regards,

Krishna

Re: S32K328: CM7_0 access to CM7_2 DTCM backdoor causes imprecise BusFault

Hi Krishna, 

Copilot said: I have tested it and was able to reproduce this error only when the default MPU is enabled in the project (configured in system.c generated by the S32DS RTD project). Could you dump the MPU registers to verify whether the MPU is disabled in your project?

Regards,

Daniel