EVMK2EX: SMARTREFLEX

Hi Mark,

For some reason the SmartReflex Control registers are not publicly available.

Let me check further.

Best Regards,
Yordan

Mark,

Are you familiar with this document: Power Management of KeyStone II Devices Application Report (SPRABX9C) available at the link below?  It should provide the information required.

Tom

In Reply to Tom Johnson: Many thanks Tom but I do have that document but there appears to be some missing information around section 1.3.1. I'm having issues setting certain bits which seem to have a knock on effect of un setting other bits. Also, this section talks about waiting for the VID status to change before setting the Comp Enable Bit. But it's not clear on the timing of it being outside status0 and status1. Plus there are no detailed definitions of any of the SMARTREFLEX registers.

Hi Yordan,

          Yes this is very frustrating. I'm doubting slightly the development board I'm using as well. But I'm sure there must be further detail available.

If you do come across any further information, I'd be very interested.

Many thanks.

Mark,

The information provided is expected to be sufficient.  The SRSS is not meant to be interactive with software.  The SRSS is a hardware-driven IP block.  The part powers up in SRc0 mode.  Software can then enable SRc0-TC, if desired.  There is no other intended interaction.  You simply need to follow the steps listed.

Let's back up to more basic questions:

1. What is your AVS power supply solution (i.e. what part)?
2. Are you planning to use the VCNTL interface to control the AVS voltage or communication over I2C?
3. Does the power supply start at the proper initial voltage per the datasheet?
4. Do you have a solution to return to this initial voltage if the K2E device is reset?
5. Does the AVS solution work correctly in default SRc0 mode?  If so, what is the voltage?  What is the VCNTLID value read form the PSC register at 00_0235_0014 and extracted from bits 21:16.
6. Are you working on a custom board?  If so, how many have you built and do they all behave the same?
7. Do you have a K2E EVM that you can use to validate your SRc0-TC implementation?

Tom

Hi Tom,

       Below are the responses to your questions:

See below for answers.

1. What is your AVS power supply solution (i.e. what part)?

   <<<< TPS544C25RVFT regulator and LM10011 DAC

2. Are you planning to use the VCNTL interface to control the AVS voltage or communication over I2C?

   <<<< 6-bit dual-phase VCNTL

3. Does the power supply start at the proper initial voltage per the datasheet?

   <<<< Yes is starts at 1.05V

4. Do you have a solution to return to this initial voltage if the K2E device is reset?

   <<<< Yes this is handled by power sequencer

5. Does the AVS solution work correctly in default SRc0 mode?  If so, what is the voltage?  What is the VCNTLID value read form the PSC register at 00_0235_0014 and extracted from bits 21:16.

   <<<< Seems to we read back VID 54 and voltage sits at 1.047V

6. Are you working on a custom board?  If so, how many have you built and do they all behave the same?

   <<<< Tried it one custom board but have also tried it on the K2E EVM

7. Do you have a K2E EVM that you can use to validate your SRc0-TC implementation?

   <<<< See above

To add, my main concern is understanding how I should use: VPRM_STATUS0_REG?!

It's not clear when this status register should be in a particular state. Effectively how do I get status register

VPRM_STATUS0_REG out of STATE0 (0) and STATE1(1). The implication being when I'm in either of these 2 states and I write

to:

/* Enable State Machine to be in CLASS 0 */

PSP_SRSS_TEMP_CTL0_REG_STORE.B.SRSS_C0_TC_MODE_EN = C_ENABLE_TO_CLASS0_TC_MODE;

It just won't go into TC mode.

I'm trying to set things up as follows (my boiled down code):

/* Enable Sensor0 */

PSP_SRSS_TEMP_CTL0_REG_STORE.B.SRSS_TSEN_0_EN = E_SRSS_TSEN_ENABLE;

/* Write back to real register */

strSRSSTempSenCtrl_Reg->B = PSP_SRSS_TEMP_CTL0_REG_STORE.B;

/* Now select Sensor to initiate Temperature Change */

PSP_SRSS_TEMP_CTL0_REG_STORE.B.SRSS_TSEN_SELECT = C_SRSS_SENSOR_FOR_COMPENSATION;

/* Write back to real register */

strSRSSTempSenCtrl_Reg->B = PSP_SRSS_TEMP_CTL0_REG_STORE.B;

/* Loop until VID_FSM_STATUS is GOOD or Timeout (10ms) */

while (loopCounter < 10000 && StatusGood==0) {

              /* Perform 32 bit read on VPRM Status Register */

              PSP_SRSS_TEMP_VPRM_STAT_REG_STORE.B = strVPRMStatus0_Reg->B;

             /* Check to see if the STATE Machine is no longer in STATE 0 or STATE 1 */

             If ((PSP_SRSS_TEMP_VPRM_STAT_REG_STORE.B.VID_FSM_STATUS != 0) && (PSP_SRSS_TEMP_VPRM_STAT_REG_STORE.B.VID_FSM_STATUS != 1)) {

                  /* Set FLAG if healthy */

                   StatusGood = 1;

               }

             /* Inc timeout counter */

              loopCounter++;

}

/* Enable State Machine to be in CLASS 0 */

PSP_SRSS_TEMP_CTL0_REG_STORE.B.SRSS_C0_TC_MODE_EN = C_ENABLE_TO_CLASS0_TC_MODE;

/* Write back to real register */

strSRSSTempSenCtrl_Reg->B = PSP_SRSS_TEMP_CTL0_REG_STORE.B;

As you can see above, I tried buffering the bit sets and then write them back as 32 bits but previously I was doing 1 writes to the actual hardware address and this caused the following behaviour:

Enable bit [bit[0] = 1]for Sensor0 in Ctrl Register.

Write 0 to  Sensor Select bit (bit[19] = 0). This caused bit[1] to go to 1, this being the enable Sensor1 bit.

I then wrote this back to 0 (disable) via the debugger.

Read VPRM_STATUS0_REG bits[0..2] for VPRM Status. This only ever seemed to read 1.

Write 1 to CTL0_REG bit bit[2] enable TC mode. This cause Ctrl Reg select Sensor bit (bit[19]) to go to '1' (select sensor1).

I then, via the debugger forced bit[19] back to 0 and this seemed to cause the TC to work, but I'm not sure if that was repeatable and we certainly didn't have the setup at that time to monitor the status of the VPRM status register.

This part just described was only tried on the EVM K2E. The first part was run on EVM K2E and a customer board with the same processor.

Hope that clarifies our position.

Mark,

That clarifies the situation as you are using TPS544C25RVFT regulator and LM10011 DAC with the 6-bit, dual-phase, hardware-only VID control.  We have sample code in ProcSDK but it covers I2C communication for the VID control.  It is grouped under K2G but is fully applicable to K2E.  You will only need a very small part of the available code which is the part that you are asking about.  It is from Processor RTOS SDK 5.3 version for K2G: C:\ti\pdk_k2g_1_0_13\packages\ti\drv\pm.  You can also get the code from here: https://git.ti.com/keystone-rtos/pm-lld.  For further software questions, I have added a software expert to this thread.

Tom

Hi Tom,

        Sorry Tom, so close and yet so far. I can't down load any of that. Is it possible you could post the code so that I can take a look at it. Sorry for the inconvenience.

Mark

Mark,

The power management example code can be download in 2 ways:

1) Through Processor SDK RTOS

Please note there is no example for K2E platform but we have it on K2G. So you can take a look at it K2G example but some porting is probably needed in order to get it to work on K2E.

http://software-dl.ti.com/processor-sdk-rtos/esd/K2G/latest/index_FDS.html

After you download it, install it and then you can find example code here:

C:\ti\pdk_k2g_version #.#\packages\ti\drv\pm.

2) Another way is through git repo

http://git.ti.com/cgit/cgit.cgi/keystone-rtos/pm-lld.git/commit/

Search for "download" on this page and then you can download the zip file.

best regards,

David Zhou

Hi David,

         I've clicked on http://git.ti.com/cgit/cgit.cgi/keystone-rtos/pm-lld.git/commit/ and downloaded, but it's still not clear where this code actually resides. You couldn't point me to the right directory and files?!

Kindest regards,

Mark

Just to be clear: This is the code that's going to enable me understand how to setup the following:

Steps to Enable SRSS Class0 Temperature Compensation Mode

1. Relevant Registers:

The following are registers relevant for the Class 0 TC setup. Perform Read Modify Write and change

only the value of required fields within the registers.

Table 2. Registers Relevant for Class 0 TC Setup

Register Name Read/Write

Register Width

(Bits)

Base Address

Within SOC

Address Offset Within

Module

Reset Value/

Comments

SRSS_TEMP_CTL0_REG RW 32 SRSS Base 0x0000 001C 0x0

SRSS_TEMP_STAT0_REG R 32 SRSS Base 0x0000 0028 0x0

SRSS_TEMP_STAT1_REG R 32 SRSS Base 0x0000 002C 0x0

VPRM_STATUS0_REG R 32 SRSS Base 0x0000 0088 0x0

2. Setup Parameters: (Thresholds for temperature, and so forth)

(a) All Keystone II devices have this programmed by default. No additional setup is needed.

3. Enable Temperature Sensors:

Keystone II devices have two on die sensors tm0 and tm1 that can be configured in order to be used

by SRSS in the class 0 TC mode to sense temperature. These can be enabled by writing to

SRSS_TEMP_CTL0_REG’s bits[1:0].

(a) Smart Reflex Sensor Power Domain should be turned on by programming the PSC (Power Sleep

Controller) module.

(b) SRSS_TEMP_CTL0_REG[0] = srss_tm0_en,

Used for Temperature Sensor 0 SRSS_TEMP_CTL0_REG[1] = srss_tm1_en, used for

Temperature Sensor 1

0: Temperature Monitor disabled locally

1: Temperature Monitor enabled locally

(c) PAPLL should be Configured and kept on for sensors to work.

(d) Only one of the two available sensors can be used at a time by the SRSS state machine to initiate

voltage change.

SRSS_TEMP_CTL0_REG[19] = srss_tempm_sel

0: Select tm0 as the source of temperature-comparison used to compare vs threshold points.

1: Select tm1 as the source of temperature-comparison used to compare vs threshold points

All Keystone II devices have this bit programmed by default to 0.

(e) Reading Temperature Value

Enabled sensor’s temperature can be read in Signed two compliment formats in the following

register:

SRSS_TEMP_STAT0_REG[7:0] = srss_tm0_temp

SRSS_TEMP_STAT0_REG[23:16] = srss_tm1_temp

4. Enable SRSS Temperature Compensation mode

(a) Make sure the SRSS state machine is not in State S0 or S1 by reading VPRM_STATUS0_REG

VPRM_STATUS0_REG[2:0] = VID_FSM_STATUS

Reflects the status of the VID FSM posting the voltage change request to the SMPS:

“0x0” FSM in state S0

“0x1” FSM in state S1

(b) The final step is to enable the State machine to be in Class 0 TC mode by the following write:

SRSS_TEMP_CTL0_REG[2] = srss_c0temp_en = 1b1

SR-Class0 temperature compensated

5. Read temperature compensated voltage (VID)

When Class0-TC mode is enabled, the suggested value of the voltage (based on the temperature of

the device) is reflected in the following register field:

SRSS_TEMP_STAT1_REG[29:24] = srss_tempthp_vctl[5:0]

This value is the temperature compensated and calculated SR-Class0 voltage target in the 6-bit VID

interface format.

Hi David,

     
I've managed to download some code from GIT: "git.ti.com/.../", but I'm still struggling to locate the specific files that contain the references to setting the Class 0 TC mode up.

I've actually achieved the setting up of this mode but it's been totally haphazard. I can only achieve it when I write directly to the hardware in the following order:

(1) Enable Sensor0 by writing '1' to SRSS_TEMP_CTL0_REG bits[0]. This effectively enables the Temperature from Sensor 0 to be read back from:

                  
                  (a) SRSS_TEMP_STAT0_REG[7:0]

(2) Define the source for compensation by writing '0' to SRSS_TEMP_CTL0_REG[19]. This actually defaults to '0'. But when I write '0' to this bit the following bit is set to '1':

                  (a) SRSS_TEMP_CTL0_REG bits[1], which enables Sensor1.

(3) Therefore, to correct this problem in the debugger, I force this bit back to '0'.

(4) I poll the following bits VPRM_STATUS0_REG[2:0]. Where the explanation in section 1.3.1 item 4 states Temperature Compensation can only be set if this value is not '0' or '1'.
I never see this value at '0' or '1' if I poll it therefore, I attempt to Poll it with a timeout with no success.

(5) I then enable Temperature Compensation by writing '1' to SRSS_TEMP_CTL0_REG[2]. This causes SRSS_TEMP_CTL0_REG[19] to go to '1' indicating that it's attempting to source the temperature from Sensor1, which is not enabled.

(6) I then force SRSS_TEMP_CTL0_REG[19] back to '0' and then sometimes when I let the debugger continue it starts to work.

Therefore, it's not clear of the handling of VPRM_STATUS0_REG[2:0].

I hope that's clearly explained my predicament.

To add, I have attempt to perform the normal sequence with writes to a ghost variable and 32 bit writes back to the hardware registers, but to no avail.

Regards,

Mark

Let me just correct something I've written above:

(4) I poll the following bits VPRM_STATUS0_REG[2:0]. Where the explanation in section 1.3.1 item 4 states Temperature Compensation can only be set if this value is not '0' or '1'.
I never see this value at ANYTHING OTHER THAN '0' or '1' if I poll it therefore, I attempt to Poll it with a timeout with no success.

So effectively it's not clear what other values  VPRM_STATUS0_REG[2:0], can be other than '0' or '1'.

Plus I was trying to get the actual bit definitions of the following rgisters:

(a). SRSS_TEMP_CTL0_REG

(b). SRSS_TEMP_STAT0_REG

(c). SRSS_TEMP_STAT1_REG

(d). VPRM_STATUS0_REG

Many thanks for your assistance.

regards,

Mark

Mark,

We have code which does the steps mentioned in section 1.3.1 of the power management app note. I am searching for it and will provide you more details soon.

best regards,

David Zhou

Hi David,

         Many thanks!

Regards,

Mark

Mark,

After some searching, here is what I found:

Smart Reflex class 0 temperature compensation is enabled on K2E EVM through the Uboot code.

https://git.ti.com/cgit/keystone-linux/u-boot/commit/

Source code is in this folder, function is srss_c0_init()

\u-boot-master\drivers\hwmon\srss.c

Then in user space, example can be found here:

https://git.ti.com/cgit/keystone-linux/srss-tc/tree/src?h=master

The user guide is attached. /cfs-file/__key/communityserver-discussions-components-files/791/3660.srss_5F00_c0_5F00_ug_5F00_1.1.pdf

In your application, are you using Linux or RTOS?

best regards,

David Zhou

Hi David,

        I'm using a bare metal RTS. Which I believe has a customised boot code.

So I'm effectively doing the SRSS initialisation outside of boot.

Am I missing something like timings or something of that nature. The only thing I see that's different, apart from the fact that I'm using c to perform 32 bit writes to the hw registers, is that I'm not clearing the interrupt mentioned here:

 /* Clear the threshold point interrupt pending flag */
 __raw_writel((1 << TEMP_THRPT_INT_SHIFT), base + SRSS_EVENT_CLR);

 __raw_writel(temp_ctl0, base + SRSS_TEMP_CTL0);

...before writing to the CTRL0 REGISTER.

Is this important. That doesn't appear to be in your document, see below:

U-boot will do the following configurations to enable SRSS C0 with TC.

• VPRM_EN set to ‘01’ (enables SRSS C0) in VPRM_CTRL0_REG

• SMPS_MODE set to ‘10’ (enable VID 6-bit interface) in VPRM_CTRL0_REG

• srss_c0temp_en set to ‘1’ (enables TC) in SRSS_TEMP_CTL0_REG

• srss_class0_i2c_req_en to ‘0’ (disables SRSS I2C) in SRSS_TEMP_CTL0_REG

 If I can set this stuff up anywhere, then I'd prefer not to have to tamper with the existing boot code. So effectively it form part of an environmental test so that we can observe the voltage regulating.

Is your code attempting to map a Temperature to Compensation value (voltage) map. Or does it just make use of the hw programmed version?

Mark,

The code I shared earlier is for Smart Reflex Class 0 with temperature compensation mode. In order for it to work, it has to be a closed loop. TC mode has to be enabled and when SRSS detects a temperature threshold point interrupts and then Linux user mode application will set a new voltage to the external power supply controller. Clearing the threshold point interrupt pending flag is part of the operation necessary.

best regards,

David Zhou

Hi David,

         I've followed the order of your code but I still couldn't get it to work. But the only thing I didn't add was the resetting of threshold point interrupt. So I'm going to try that now.

None of this information has been available in documentation until I received this stuff from you. So many thanks for that. 'SPRABX9' just didn't have enough information in it.

I'll probably be back to you soon with my results.

The only difference between my code and yours is that I'm writing to 32bit local variables and writing them back to the necessary registers. There shouldn't be any issue with that should there?!

Are you saying that the interrupt goes to a specific routine that manages the change in voltage. I'm not aware of a handler that does that. I don't believe that's part of our platform level code. We have a bare metal RTS on that board for the moment, we don't have a Linux environment.

Regards,

Mark

Hi David, The follow up is I've added the setting of the Threshold interrupt just before I set the TC enable bit along with the enabling of the sensors, which your code seems to do together.

I then heat up the processor with a heat gun and it still doesn't change. When I was setting bits in the hw registers directly, occasionally it would leap into life and we would see a change from 54 to 52 when the Sensor Temperature got to 60 degressC it would then go back to 54 as soon as it dropped below.

As I previously stated I'm running this code after our boot code has completed and we run into an environment test software.

We have two loops one that is performing initialisation software and I've set the TC initialisation at the end of that loop.

The only part I don't understand is the management of the call on the threshold change interrupt.

I was expecting this to be a part of the processor firmware and that the hardware would effectively cause the change.

The fact that we've managed to get this working would imply that everything is in place it's just that there is still something specifically missing with the register setup.

Mark,

Are you doing this test on TI's K2E EVM or your custom board? If it is your custom board, what is the power supply controller you are using? Does it have an I2C/PMBus interface and it was connected to K2E I2C port?

You can enable Smart Reflex class 0 with TC mode in the bootloader, that is fine and I believe you did this part. But how about the application part? Please take a look at section 5.2.2 in user's guide. Application, when received SRSS temperature threshold point interrupt, need to use I2C interface to communication voltage change to power supply controller.

/cfs-file/__key/communityserver-discussions-components-files/791/3660.srss_5F00_c0_5F00_ug_5F00_1.1.pdf

Please note we only have example on Linux, not RTOS or bare-metal. So you will have to copy the idea and implement it for RTOS or bare-metal.

best regards,

David Zhou

Hi David, I'm currently using TI's K2E EVM. I wasn't aware that I had to use I2C?! But we are going to use the custom board. But I thought the VID interface and the SMARTREFLEX registers didn't require any other setup. What I'm using is serial COM (putty) output to display the sensor0 and sensor1 values to screen and the VID value '54'.

We can heat up the processor on the EVMK2E and the Sensor Temperatures go up.

We use the following registers:

/** @brief SmartReflex0 - THRESHOLD_EVENT_REG - Address 0x0233000Cul */

define C_SRSS_EVENT_CLRREG_BASE (C_SMARTREFLEX0_BASE + 0xC)

/** @brief SmartReflex0 - TEMP_CTRL0_REG - Address 0x0233001Cul */

#define C_SRSS_TEMP_CTL0REG_BASE (C_SMARTREFLEX0_BASE + 0x1C)

/** @brief SmartReflex0 - TEMP_STATUS0_REG - Address  0x02330028ul*/

#define C_SRSS_TEMP_STAT0REG_BASE (C_SMARTREFLEX0_BASE + 0x28)

/** @brief SmartReflex0 - TEMP_STATUS1_REG - Address 0x0233002Cul */

#define C_SRSS_TEMP_STAT1REG_BASE (C_SMARTREFLEX0_BASE + 0x2C)

/** @brief SmartReflex0 - VPRM_CTRL0_REG - Address 0x02330080ul*/

#define C_VPRM_TEMP_CTL0REG_BASE (C_SMARTREFLEX0_BASE + 0x80)

/** @brief SmartReflex0 - VPRM_STATUS0_REG - Address 0x02330088ul */

#define C_VPRM_STATUS0REG_BASE (C_SMARTREFLEX0_BASE + 0x88)

So for the Sensor Temperatures we read from:

/* Set pointer to C_SRSS_TEMP_STAT1REG_BASE register */

struct PSP_SRSS_TEMP_STAT0_REG_Type * const strSRSSTempSenStat0_Reg =

(struct PSP_SRSS_TEMP_STAT0_REG_Type * const) C_SRSS_TEMP_STAT0REG_BASE;

/* Set Status1 Register Store to Real Status1 Register Read Back Value */

PSP_SRSS_TEMP_STAT0_REG_STORE.B = strSRSSTempSenStat0_Reg->B;

/* Check Sensor Number */

if (enumTSenID==E_SRSS_SELECT_TSEN_0) {

/* Set local variable to current compensated temperature reading from Sensor 0 */

ReadTemperature = PSP_SRSS_TEMP_STAT0_REG_STORE.B.SRSS_TEMP_SENSOR0;

}

/* Set local variable to current compensated temperature reading from Sensor 1 */

else ReadTemperature = PSP_SRSS_TEMP_STAT0_REG_STORE.B.SRSS_TEMP_SENSOR1;

...and for the COMPENSATED Voltage VID code we read from:

/* Set pointer to C_SRSS_TEMP_STAT1REG_BASE register */

struct PSP_SRSS_TEMP_STAT1_REG_Type * const strSRSSTempSenStat1_Reg =

(struct PSP_SRSS_TEMP_STAT1_REG_Type * const) C_SRSS_TEMP_STAT1REG_BASE;

/* Set Status1 Register Store to Real Status1 Register Read Back Value */

PSP_SRSS_TEMP_STAT1_REG_STORE.B = strSRSSTempSenStat1_Reg->B;

/* Extract value to be returned */

ReadVoltage = PSP_SRSS_TEMP_STAT1_REG_STORE.B.SRSS_TEMP_THP;

Having obviously first off set up the registers. But we don't do that in bootup we have our own application that runs after bootup and there we initialise things for our own Environmental Test application.

As I mentioned before, I'm using 32bit global variables to store the bit writes before writing them back to the hw registers. But I was having more success when I was poking the bits in the hw registers whilst in the debugger. It didn't always work but using the current setup I can't get it to work.

I was expecting this to be so difficult to setup.

Regards,

Mark

David,

       In that document you provided it states: "Please refer to SRSS IP UG (TBD) for detailed description of the registers. Is that detail available anywhere?

Still confused as to why I can't set this up. But just to refer back to your last message, if I've setup the Class0 TC mode, do I need any other setup if my application code just reads all the relevant registers and outputs the values via putty.

I'm not sure what the LINUX USERSPACE APP section in the document is giving me?!

This was basically a task to support our hw engineers so that they could place the board in an oven and study the compensation process in action.

Regards,

Mark 

Mark,

To be sure: are you using class 0 only or class 0 TC?

I assume you are using class 0 TC mode since you mentioned that in your first post.

For class 0 TC mode, we only have demo on Linux, not RTOS. You are going to directly implement on your own with bare-metal, that is where the challenge is. I would recommend you just go back to Linux to understand our demo first before you implement on your own.

This is MCSDK version which support this demo:

http://software-dl.ti.com/sdoemb/sdoemb_public_sw/mcsdk/latest/index_FDS.html

The latest Processor SDK, however dropped this demo.

best regards,

David Zhou

David,

SmartReflex in the K2E can be controlled over I2C using a software-driven implementation OR it can be supported over the VCNTL pins in a hardware-only implementation.  The hardware solution is automatic once it is enabled through software at start-up.  There is no requirement for continuous software involvement once it is turned on.

Tom

Guys,

     That's what I'm trying to achieve and it's proving difficult. I've started with the instructions in the document spra

so going back to the statement:

(a) Make sure the SRSS state machine is not in State S0 or S1 by reading VPRM_STATUS0_REG

VPRM_STATUS0_REG[2:0] = VID_FSM_STATUS.

David, this is in your software but only in the setup of VPRM.

I'm thinking now that I probably don't need to do this step:

/* Start by setting VPRM_ENABLE true and SMPS_MODE to enable VID Interface */

PSP_SRSS_TEMP_VPRM_CTRL_REG_STORE.B.VPRM_EN = 1;

PSP_SRSS_TEMP_VPRM_CTRL_REG_STORE.B.SMPS_MODE_VID = 2;

Mainly because the VPRM_EN is already set to '1', but I'm not sure about the SMPS_MODE_VID being set to '2'.

This was the original list of things to setup as defined in SPRABX9C:

1. Relevant registers

The following are registers relevant for the Class 0 TC setup. Perform Read Modify Write and change

only the value of required fields within the registers.

SRSS_TEMP_CTL0_REG  RW 32 SRSS Base 0x0000 001C 0x0

SRSS_TEMP_STAT0_REG     R 32 SRSS Base    0x0000 0028 0x0

SRSS_TEMP_STAT1_REG     R 32 SRSS Base    0x0000 002C 0x0

VPRM_STATUS0_REG           R 32 SRSS Base     0x0000 0088 0x0

2. Setup Parameters: (Thresholds for temperature, and so forth)

   (a) All Keystone II devices have this programmed by default. No additional setup is needed.

3. Enable Temperature Sensors:

     Keystone II devices have two on die sensors tm0 and tm1 that can be configured in order to be used

     by SRSS in the class 0 TC mode to sense temperature. These can be enabled by writing to SRSS_TEMP_CTL0_REG’s bits[1:0].

   (a) Smart Reflex Sensor Power Domain should be turned on by programming the PSC (Power Sleep

         Controller) module.

   (b) SRSS_TEMP_CTL0_REG[0] = srss_tm0_en,

       Used for Temperature Sensor 0 SRSS_TEMP_CTL0_REG[1] = srss_tm1_en, used forTemperature Sensor 1

         0: Temperature Monitor disabled locally

         1: Temperature Monitor enabled locally

    (c) PAPLL should be Configured and kept on for sensors to work.

    (d) Only one of the two available sensors can be used at a time by the SRSS state machine to initiate voltage change.

        SRSS_TEMP_CTL0_REG[19] = srss_tempm_sel

         0: Select tm0 as the source of temperature-comparison used to compare vs threshold points.

         1: Select tm1 as the source of temperature-comparison used to compare vs threshold point

         All Keystone II devices have this bit programmed by default to 0.

    (e) Reading Temperature Value

         Enabled sensor’s temperature can be read in Signed two compliment formats in the following register:

        SRSS_TEMP_STAT0_REG[7:0] = srss_tm0_temp

        SRSS_TEMP_STAT0_REG[23:16] = srss_tm1_temp

4. Enable SRSS Temperature Compensation mode

   (a) Make sure the SRSS state machine is not in State S0 or S1 by reading VPRM_STATUS0_REG

        VPRM_STATUS0_REG[2:0] = VID_FSM_STATUS

        Reflects the status of the VID FSM posting the voltage change request to the SMPS:

       “0x0” FSM in state S0

       “0x1” FSM in state S1

   (b) The final step is to enable the State machine to be in Class 0 TC mode by the following write:

        SRSS_TEMP_CTL0_REG[2] = srss_c0temp_en = 1b1

         SR-Class0 temperature compensated

The following two parts seem to throw further shadow on the essential setup.

6. Detecting voltage change request:

    (a) Read VID change by monitoring SRSS register

    (b) Interrupt triggered

7. Updating the Voltage output of the voltage controller (for example, TPS544Cxx type regulator)

    (a) VCNTLID bus

    (b) Generic I2C bus

I was hoping this would be as simple as performing sections 1 to 4 above and then I could let hw perform their environmental tests heating the processor card and monitoring the compensation process in action?! I'm now totally confused as to what is the minimum I need to setup.

Guys,

     To be truthful, it's this part (bold below) that is causing the problem because I never see it set to anything but '1':

4. Enable SRSS Temperature Compensation mode

   (a) Make sure the SRSS state machine is not in State S0 or S1 by reading VPRM_STATUS0_REG

         VPRM_STATUS0_REG[2:0] = VID_FSM_STATUS

             Reflects the status of the VID FSM posting the voltage change request to the SMPS:

             “0x0” FSM in state S0             

             “0x1” FSM in state S1

But it's not clear what values it can have other than 0 or 1?!

The implication is that if it is any other then following bit will work: 

     (b) The final step is to enable the State machine to be in Class 0 TC mode by the following write:

           SRSS_TEMP_CTL0_REG[2] = srss_c0temp_en = 1b1 (SR-Class0 temperature compensated)

Apologies for taking up both your time. But the lack of clarity in the information is proving difficult to find a resolution.

Feel like I'm going round in circles at the moment.

Regards,

Mark

One last point:

                before setting:  SRSS_TEMP_CTL0_REG[2] = srss_c0temp_en = 1b1, do I still need to write to  register SRSS_EVENT_CLR[17], I'm thinking probably not as that is part of the software driven version. Also as SMARTREFLEX is already setup I presume I don't need to set VPRM_CTRL0_REG for VPRM_ENABLE | SMPS_MODE_VID. VPRM_ENABLE is automatically set, but should SMPS_MODE_VID. In your code David you state that you can only set these bits while VPRM_STATE0_REG is State0 or State1 and you actually have a while loop waiting or that to be the case before you set them. I've never seen this set to anything but '1'.

Just to clarify one more time: I'm performing the initialisation of all this within the application code. There is an initialisation part where I setup as indicated, and a frame set up part where I continuously read the Sensor Temperatures and the VID value (continuously '54') from the COMPENSATED Voltage Read back.

Not sure where to go from here with this!

Regards,

Mark

Mark,

I am sorry I don't have all the answers. If you have doubt about the app note, you can refer to the code as code is the implementation.

The Linux code supports srss_vcntl as environment variable to control. If this environment variable in Uboot is set to 1, then it will select SRSS C0 with TC over VCNTL interface rather than I2C. So if you are not using I2C, those two lines about clearing interrupts appears to be not necessary but it won't hurt the function.

In user's guide, section 5.1.1.2, it says: "Note Temperature compensation cannot be verified on existing version of TI's EVM due to board related problem, and some devices on TI's EVM does not has TI's EVM does not have SRSS e-fuse registers programmed. But customers can measure the Vout on the board to check if it matches with the initial VID value". Can you check on your EVM? Register 0x2620180, 0x2330080, 0x2330084.

best regards,

David Zhou

Hi David, Apologies if I've come across wrong I much respect your input.

I think I want to concentrate on the following question: "How do I get

VPRM_STATUS0_REG[2:0] = VID_FSM_STATUS to a value > 1.

It states in SPRABX9C that this has to be greater than 1 to be enable to enable the bit: srss_c0temp_en in SRSS_TEMP_CTL0_REG[2].

The problem I never see it at anything other than 1.

We may have got it to this value during some of this debugging exercise but I still need clear instructions to achieve that.

Apologies if I appear to be repeating myself!

Kindest regards,

Mark

Tom,

      The same question to you:

Are you aware of how to get this Status to the necessary value or why I can't see it at anything but '1'.

"How do I get VPRM_STATUS0_REG[2:0] = VID_FSM_STATUS to a value > 1.

It states in SPRABX9C that this has to be greater than 1 to be enable to enable the bit: srss_c0temp_en in SRSS_TEMP_CTL0_REG[2].

The problem I never see it at anything other than 1.

We may have got it to this value during some of this debugging exercise but I still need clear instructions to achieve that.

Apologies if I appear to be repeating myself!

Kindest regards,

Mark

David/Tom,

              SPRABX9C states "To enable the Class 0 with Temperature Compensation mode, additional steps are needed after device boot". My question is, is this the case anytime after device boot?!

At the moment I'm doing all of this initialisation in my application code and on the development board I'm powering up boot and then running the C0 TC initialisation via the debugger so is that an issue. I was imagining that I could enable this whenever I wanted to. But the fact that the VPRM_Status never changes gives me the impression I've missed my window of opportunity.

Kindest regards,

Mark

Hi David, What I am after is a precise definition of the following registers:

Base Address: 0x02330000

/* Smart Reflex Sub-System register offset */
#define SRSS_PID 0x0
#define SRSS_INTR_EN_SET 0x4
#define SRSS_EVENT_FLAG 0x8
#define SRSS_EVENT_CLR 0xc
#define SRSS_TEMP_CTL0 0x1c
#define SRSS_TEMP_CTL1 0x20
#define SRSS_TEMP_CTL2 0x24
#define SRSS_TEMP_STAT0 0x28
#define SRSS_TEMP_STAT1 0x2c
#define SRSS_VPRM_CTL0 0x80
#define SRSS_VPRM_CTL1 0x84
#define SRSS_VPRM_STAT0 0x88
#define SRSS_VPRM_STAT1 0x8c

Also could you take a look at the order of the things I'm trying to setup to see if I'm missing an important step.

1) Read 32 bits from SRSS_VPRM_STAT0, Check to see if value read back is > 1. This is to ensure that not in State0 or State1

2) If goes to State other than 0 or 1:

       Write 32 bits (0x00000005 hex to address: 0x0233001C) This sets SENSOR01_ENABLE and TC_ENABLE (as based on SPRABXC9)

   else, do nothing 

The documentation categorically states that it is automatically in Class0 mode and that Sensor0 is selected by default.

What I would like to understand is which register categorically states that Class0 TC mode is active.

Going back to 2) above, it's still not clear how SRSS_VPRM_STAT0 goes to a different state. The documentation states:"Reflects the status of the VID FSM posting the voltage change request to the SMPS".

But it's not clear what state (0, 1 or otherwise) represents this phase and how I can definitely get it to a different phase to enable Class0 TC mode. Is any of this information available.

Apologies if I'm sounding desperate but this is holding up our testing of hw.

Regards,

Mark

 Mark,

I understand your situation but I also found the smart reflex registers for K2E is not even published. I don't have it either. There must be some history on why it happened this way but I don't know. In my opinion, this feature is not fully complete without register definition in user guide and software examples for both Linux and RTOS (or bare-metal).

Here is the feedback I got from the engineer who implemented the Linux code:

"When SR C0 TC is enabled, user can use a heat gun to change the SoC temperature, once the temperature changes and exceeds a threshold, SRSS_TEMP_STAT1_REG[29:24] will show a new VID value. I believe VID_FSM_STATUS in VPRM_STATUS register should also change, but the current user mode application does not monitor the VID_FSM_STATUS change."

best regards,

David Zhou

Hi David,

     Many thanks for coming back so promptly.

I was wondering if the difference between your version of software and what I'm trying to achieve is based on the fact that Class0 mode is a default mode, whereas, your code seems to set it.

I'm now wondering if I need to take it out of Class0 mode (by setting VPRM_EN = 0 (Disable) in VPRM_CTR0_REG and then monitor the VPRM_STATUS_REG and see what impact that has and then set it back (Enable) and see if it changes again.

Is that something you could confirm with the same engineer.

I'm going to try it a bit later. I'm going to be out of the office from about 15:15 to 17:15 GMT. What time are you guys available till?

Kindest regards,

Mark

Mark,

Yes, I believe that will be a good test to see the difference (disabled vs enabled).

best regards,

David Zhou

HI David,

      Just to give you an update to the situation. I tried setting VPRM_CTRL1_REg bits (0x02330080) 0 to 1 to '1' (VPRM_ENABLE) and monitoring the Register TEM_STATUS0_REG 0x02330088. The status basically just mimicked the this value. So, when 'VPRM_Enable' was '0' 'VID_FSM_STATUS' was '0' and vice versa.

Therefore, my next question goes back to the list in document 'SPRABX9C':  (a) Smart Reflex Sensor Power Domain should be turned on by programming the PSC (Power Sleep Controller) module.

Does this mean that there is a time limit between powering the PSC and then performing all of the setup and if this is the case could I de power and then re power them in my application code???

Regards,

Mark

Hi David,

          Some further update. I've constructed a call chain from your code that you provided me with:

/* workarounds:
  * 1: select PA PLL clock souce after powering on PA clock domain;
  * 2. initialize SRSS after configuring PA clock since SRSS uses PA clk
  */
 if (psc_enable_module(KS2_LPSC_PA))
  return -1;
 pll_pa_clk_sel(1);

#ifdef CONFIG_SRSS_C0
 i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);

 /* inistialize SRSS class 0 */
 srss_c0_init(KS2_SRSS_BASE, srss_tps544_init);
#endif

 return 0;
}

You can see that the Class0 and subsequent TC enable is performed initialising SRSS directly after configuring PA clock since SRSS uses PA clk.

My point is, does this have to be done here? This would imply that there is a finite time when setting C0 TC can be performed??!!

I need some confirmation on this because I would need to modify our own boot code to attempt it.

Kindest regards,

Mark

Mark,

Do you use your own code or calling psc_enable_module() APIs?

If you are calling psc_enable_module() APIs, you should be good. Typically when you power on a module, it should be done and does not return an error code. However, the code is written in a way to protect worst cases. There is a timeout limit on checking PSC PTSTAT, it is defined to be 100, the wait function will be called 100 before giving up. If you are already calling the APIs, this should not be concerned unless if you do see the function call return an error code.

In the app note, it does mention: PAPLL should be configured and kept on for sensors to work. So yes, if you have not done this in your code, you need to add it.

best regards,

David Zhou

Mark,

Just to follow up on this thread: are you making some progress? How can we further help you?

best regards,

David Zhou

Hi David,

          Thanks for coming back! Unfortunately I haven't quite cracked it yet. I've tried moving the Class0 TC initialisation into BOOT but that still doesn't seem to fix it.

Just to reiterate, we've only seen the TC functionality working when we were performing the following:

(1). Using a heat gun to warm the processor. The temperature crept up around 60 degrees.

(2). Performing resets on the EVMK2E board by pressing the BMC reset button.

(3). Loading the application (which happens after BOOT has completed), via Code Composure.

(4). Stepping through my original code which was as follows:

        Manually setting up the following via the debugger:

       (a). SRSS_TSEN_0_EN = 1 (Enables sensor 0 - Sensor 1 is left disabled) (SRSS_TEMP_CTL0_REG bit 0)

       (b). SRSS_TSEN_SELECT = 0 (Sensor 0 is the source).

              The problem on this one was that as 0 was written to SRSS_TSEN_SELECT the signal SRSS_TSEN_1_EN went to 1.

       (c). Therefore, I forced SRSS_TSEN_1_EN back to 0.

       d). SPRABX9C originally stated that before setting SRSS_C0_TC_MODE_EN to 1 first check the following signal:

            (I) When VID_FSM_STATUS is not equal to 0 or 1. The problem was that this never appeared to be anything other than 1. (VPRM_STATUS0_REG[2:0])

      e) Therefore, I just set SRSS_C0_TC_MODE_EN = 1 (SRSS_TEMP_CTL0_REG[2])

I then let the software run and continue and, based on the list above, we have seen it start to compensate, which it does as follows:

VID value changes from "54" to "52" when the temperature >=60degrees. When the temperature drops below 60degrees it does back to "54".

There appeared to only be one step.

My other query on this is as I have to heat the processor with a heat gun in order to see whether Class0 TC is enabled could you tell me a more easier way to know if its is enabled or not.

I'm expecting one of the SRSS registers which I have the following list but have absolutely no definitions for:

#define SRSS_PID 0x0
#define SRSS_INTR_EN_SET 0x4
#define SRSS_EVENT_FLAG 0x8
#define SRSS_EVENT_CLR 0xc
#define SRSS_TEMP_CTL0 0x1c
#define SRSS_TEMP_CTL1 0x20
#define SRSS_TEMP_CTL2 0x24
#define SRSS_TEMP_STAT0 0x28
#define SRSS_TEMP_STAT1 0x2c
#define SRSS_VPRM_CTL0 0x80
#define SRSS_VPRM_CTL1 0x84
#define SRSS_VPRM_STAT0 0x88
#define SRSS_VPRM_STAT1 0x8c

So my next series of questions related to what exactly needs to be setup and in what order:

At the moment I'm powering the following:

(1). Power up PA Domain
(2). Power up PA Clock Domain
(3). Power up SMARTREFLEX Domain
(4). Power up SMARTEFLEX Clock
(5). Enable PAPLL.
(6). Enable SRSS registers as described above.

I need some clarification of that order being correct.

Also David I couldn't see where you were Powering the PA Domain or the SMARTREFLEX registers in your code?!
I'm basing the analysis of your code on the function int misc_init_r in keystone_common.c.
Could you please confirm that I'm looking in the correct as well.

Kindest regards,

Mark

Hi David,  Apologies for being so direct but I can't continue with software development until I get complete information on the correct order of initialisation for the SMARTREFLEX registers including the behaviour and definition of all of the registers:

#define SRSS_PID 0x0
#define SRSS_INTR_EN_SET 0x4
#define SRSS_EVENT_FLAG 0x8
#define SRSS_EVENT_CLR 0xc
#define SRSS_TEMP_CTL0 0x1c
#define SRSS_TEMP_CTL1 0x20
#define SRSS_TEMP_CTL2 0x24
#define SRSS_TEMP_STAT0 0x28
#define SRSS_TEMP_STAT1 0x2c
#define SRSS_VPRM_CTL0 0x80
#define SRSS_VPRM_CTL1 0x84
#define SRSS_VPRM_STAT0 0x88
#define SRSS_VPRM_STAT1 0x8c

Also whether the following order is correct:

(1). Power up PA Domain
(2). Power up PA Clock Domain
(3). Power up SMARTREFLEX Domain
(4). Power up SMARTEFLEX Clock
(5). Enable PAPLL.
(6). Enable SRSS registers as described above.

I'm having to suspend development as I can't justify hours of attempts to get it working. I'm going to need a lot more clarity.

Apologies once again for being direct.

Kindest regards,

Mark

Mark,

I understand the difficulty you are facing. Through some efforts, I was able to find the internal spec for smart reflex now which includes all the details about registers. Would you be willing to do an NDA with us? If yes, I will start an email with you directly.

best regards,

David Zhou

Hi David,  

         I just want to check with you if the following is the correct assumption:

In your code SRSS Domain and Clock are enabled/powered up after PLL_PA clock has been selected.

I noticed that we were powering up the SMARTREFLEX PD and Clock before PLL PA had been called.

I'm now thinking that may be the problem?!

Is that likely to be my issue?

Kindest regards,

Mark

Mark, David,

The PAPLL clock needs to be programmed and locked before the SmartReflex block is programmed.

Tom

Tom,

Does this mean the app note (power management of Keystone II device) is incorrect as it put PAPLL step as step c before step a?

Mark,

As I mentioned earlier, the Linux code should be correct. If there is discrepancy between the app note and code, follow the code.

best regards,

David Zhou

Hi David,

      I would like to do an NDA, if that's possible?!

Let me know what you need from me!

Kindest regards,

Mark

Thanks Tom,

               I shall make that change!

Kindest regards,

Mark

Thanks David,

               I shall make that change!

Kindest regards,

Mark

Hi David,

      This is the current status of the initialisation of the SMARTREFLEX registers:

We appear to have a semi success with the solution provided to us.

We initialise the hardware and we see that a change in temperature causes the VID code to change as follows:

a) <34degrees VID: 54

b) 34-49degrees VID: 52

c) 50-57degrees VID: 50

d) 58-70degrees VID: 48

e) >71degrees VID: 46.

But there is no detectable change in voltage and no request going across the parallel bus???

Is there something in the initialisation or maintenance that's still missing?!

Regards,

Mark