AURIX™ Forum Discussions

[MathewCrawford]

I am experiencing a problem with Enabling the SSH for one of our SRAM. We are working with the Tricore TC334LP, and trying to enable the SSH (ultimately to run SRAM Init) for DMEM, PMEM, AND DMEM1. The processing that we are using appears to work correctly for both DMEM and DMEM1, but the same processing for PMEM results in some kind of lock-up. I can step thru with a (Lauterbach) debugger successfully, but when free-running it gets hung up in the wait loop immediately after enabling the PMEM SSH, using either:

MTU_MEMTEST0.B.CPU0_PMEM_EN = 1U;
or:
MTU_MEMTEST0.U |= 0x00000004U;

Prior to this enable, we are jumping to the init routine with a link (rather than function call), disabling PCACHE (as well as DCACHE - in case it might have been enabled in boot), enabling the MTU, disabling the write-protection for registers (SAFETY ENDINIT), and disabling Error Reporting to the SMU for the SSH (MISCE and OPENE). As I have said, this logic seems to work fine for DMEM and/or DMEM1, but the same logic does not work for PMEM SSH enable.

[DownyK]

Hi, Mathew Crawford

when you test PMEM, which core do you use?

The core should not check its own SRAMS because of Stack usage. 

Therefore I recommend Core1 checks Core0 located RAMs and vice versa.

[MathewCrawford]

Unfortunately, we are single-core, so we are trying to implement this with no stack nor RAM variable access.

[Yuva]

Hello,

Please update the following details

1. Does it continue after some time or is it stuck forever?
2. What content is put in PSPR memory with the linker script?
3. Is there a possibility for any interrupts to happen?
4. Are there chances for other masters to access PMEM?

Thanks.