RM46L852: ESMSR[4] read 0xc0000000 after power-cycle

Hello,
In the device TRM is stated that after nRST values of ESMSR[4] remain unchanged but after PORRST they will be reinitialized to the default state - 0.
All bits in ESMSR[4] registers after PORRST must be 0.
You could monitor DCC module for errorrs. The DCC2 error signal is mapped to ESM group1 channel 62. ESM Group 1 errors have a configurable interrupt response and configurable ERROR pin behavior.

Best regards,
Miro

Hello, Miro,

Thanks for prompt response.
Our test is to cut of the power to the RM46L852-based board. Since PORRST would clear ESMSR registers. so the errors must occur on the way of boot-up after power-on.
I looked at our previous test data, the most frequent errors on power cycle test are shown in ESMSR1 (0x80000000) and ESMSR2(00000004). Those errors correspond to group 1 channel 31 (CCMR4 self test failure) and group 3 channel 2(CCMR4 compare failure).
My question is whether those errors occur occasionally
1. due to RM46 chip itself from CCM module,
2 or due to our board design,
3 or due to improper boot-up initialization.
Your advise is appreciated.

Regards,
Jeff

Hello,
CPU Compare Module for Cortex-R4F (CCM-R4F) compares the core compare bus outputs of two Cortex-R4F CPUs running in a 1oo1D (one-out-of-one, with diagnostics) lockstep configuration. Any difference in the core compare bus outputs of the CPUs is flagged as an error. For diagnostic purposes, the CCM-R4F also incorporates a self-test capability to allow for boot time checking of hardware faults within the CCM-R4F itself.
Even if you are using self-tests, initialization should pass if everything is working as expected.
Could you attach your sys_startup.c and sys_selftest.c files?

Best regards,
Miro

0842.sys_startup.c7750.sys_selftest.cHello, Miro

We do perform ccm self-test as seen in the startup code. However, the CCM-R4F errors  was detected prior to ccm self-test. Please search for "2883911" in sys_startup.c  for more info.

Thanks,

Jeff

Hi, Miro,

This issue was observed in our power-cycle tests, however the issue does not occur in our warm-boot test.

I am not sure if that gives any clue to the root cause. Please let me know if there is any findings or more information we can provide.

Thanks,

Jeff

Hi Jeff,

The Hercules MCUs include dual Cortex-R4F CPUs running in a lock-step operation mode. A core compare module (CCM-R4) compares the output signals from each R4F CPU. Any difference in the two CPUs’ outputs is flagged as a fault of a high-severity level. The CPU internal registers are not guaranteed to power up in the same state for both the CPUs. The CPU pushes the internal registers on to the stack on a function call, which could lead to the detection of a core compare error. Therefore, the CPU internal core registers need to be initialized to a predefined state before any function call is made.

Please initialize the CPU register after bootup.

/* Initialize Core Registers to avoid CCM Error */
_coreInitRegisters_();

Hi, QJ,

Thanks for your advice. 

It seems that _coreInitRegisters_() is called in start.S before jumping to main(). (see attached file). Please review it, maybe it misses some core register(s) ?.

In power-cycle case, it is assumed that all core registers should be set to defined values, maybe there is some exceptions to this?4810.reset.S

Thanks,

Jeff

Hello Jeff,

Which function is called after power-up, reset.S or start.S? Which compile IDE do you use?

It is better to initialize the CPU internal core registers need to zero after power up.

Hi, QJ

it is reset.S (sorry, start.S was a typo, there is no start.S file in our code base). 

Our compiler is GNU  arm-none-eabi-gcc.

arm-none-eabi-gcc (crosstool-NG crosstool-ng-1.22.0) 5.2.0
Copyright (C) 2015 Free Software Foundation, Inc.

Thanks for help, please let us know if more info is needed.

Jeff

Hi Jeff,

Do you still use sys_startup.c generated by HALCoGen which calls _coreInitRegisters_() deined in your reset.S? Just make sure that the CPU registers are initialized before using them.