AnsweredAssumed Answered

RCPM Doze/Wake-Up features buggy on P4080?

Question asked by Renato Mancuso on Jan 29, 2016
Latest reply on Feb 18, 2016 by Renato Mancuso

We use a Freescale P4080 with major revision number 2, minor rev. number 0. I will refer to two pieces of documentation for the P4080:


[1] The "P4080 QorIQ Integrated Multicore Communication Processor Family Reference Manual" (P4080RM) - we have Rev. 0, 04/2011

[2] The "P4080 Advanced QorIQ Debug and Performance Monitoring Reference Manual" (P4080DEBUGRM) - we have Rev. E, 06/2011


The question regards the functionality of the Run Control and Power Management Unit (RCPM). This unit has two interfaces: one for power management that is described in [1] at Chapter 26; and a second one that performs run control in response to platform events, mapped in DCSR space and described in [2] in Section 11.


Out of all the possible power states that are available to be selected in the RCPM, we are only interested in Full-on mode and Dozing mode for power-saving techniques.


According to the two pieces of documentation, and following the description of the RCPM in [2], the registers CGACRE 0-15 can be used to select an run control action in response to a SCU event.

Each of the CGACRE 0-15 registers exposes a PCAC field for passive core action control as well as an ICAC field for intrusive core action control.


First of all, the ICAC field in the P4080DEBUGRM Rev 0 is not directly documented, but only mentioned in Chapter 12, Section and Section After some investigation, I have found that the ICAC field corresponds to bits 24-27 of the CGACRE registers. Here is the mapping of ICAC value to action, again according to the observed behavior of the platform:


1. ICAC = 0010 -> Cores in corresponding core group are put in "Debug Halted"

2. ICAC = 0100 -> Cores in corresponding core group are requested to enter "Dozing" status

3. ICAC = 0001 -> Cores in corresponding core group are requested to exit "Dozing" status and resume Full-on mode operations


Now, I configure two SCU, say SCU0 and SCU1 so that each generates a non-sticky event roughly every 2 seconds, with a phase of 1 second, leading to the sequence:

Time 0s: SCU0 event; Time 1s SCU1 event; Time 2s SCU0 event; Time 3s SCU1 event; ...


I configure CGACRE0 (in response to a SCU0 event) to send a enter-dozing request to Core 0.

Similarly, I configure CGACRE1 (in response to a SCU1 event) to send a exit-dozing request to Core 0.


However, the behavior of the system is not the one expected, because: at Time 0, Core 0 correctly enters dozing; at Time 1, Core 0 resumes operations exiting from dozing status; at Time 2, however, Core 0 does not enter dozing anymore and any other dozing request from the RCPM unit is ignored by the core.


Note 1: If the ICAC field in the CGACRE1 (in response to SCU1 events) is cleared, indicating no action, requests of dozing from SCU0 are processed correctly.


Note 2: Even if the configuration of SCU0 is altered so that after firing a first event, no further events are generated, programming the ICAC field of CGACRE0 with "0001" is enough to prevent any dozing request to be successful.


Note 3: In our default configuration, the field MSR[DE]=0 and DBCR[IDM]=1. Hence, an action from SCU1 triggers the occurrence of a Imprecise Debug Event (IDE). However, if DBCR[IDM]=0 (hence suppressing the occurrence of the IDE condition) the behavior of the system does not change.


In summary, we would like to know whether this is an "expected" behavior of the platform or rather a problem of the particular chip revision that we are using (P4080 Rev. 2.0).