SRC GPRx Register Usage

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

SRC GPRx Register Usage

1,395 Views
jeffthompson
Contributor V

Can the MIMXRT1062 system reset controller general purpose register s be used by an application?

According to the SDK API reference manual,

General purpose registers (GPRx) would hold the value during reset process. Wakeup function could be kept in these register. For example, the GPR1 holds the entry function for waking-up from Partial SLEEP mode while the GPR2 holds the argument. Other GPRx register would store the arbitray values.

The processor reference manual says

This register is used by the ROM code and should not be usedby application software.

So are they safe to use or not?

Labels (1)
0 Kudos
8 Replies

1,288 Views
Sabina_Bruce
NXP Employee
NXP Employee

Hello Jeff,

Hope you are doing well.

It is clear that some of these registers already have specific purposes such as SRC_GPR1/2. For the registers that have a clear intention I wouldn't recommend to attempt to change the value as it may cause unexpected behavior. From an initial perspective I wouldn't use them even if it states that they are for arbitrary values as they may be used in the future by the ROM code even if not at the moment. In addition, I am checking with our application's team if there are any implications or considerations to be taken for those general purpose registers that have only been described for arbitrary values. I will update you on that as soon as I have a response.

 

If you are looking for a register that can be capable of maintaining values, I'd recommend to check the SNVS_LP general purpose register. More information can be found in section 20.4.2.1. Please note, that for this you will have to consider adding an uninterrupted power source such as a coin cell battery.

 

Hope it helps!

Sabina

-----------------------------------------------------------------------------------------------------------------------

Note: If this post answers your question, please click the Correct Answer button. Thank you!

-----------------------------------------------------------------------------------------------------------------------

0 Kudos

1,288 Views
jeffthompson
Contributor V

I’m actually using SNVS->LPGPR[x].

Jeff Thompson | Senior Electrical Engineer-Firmware

+1 704 752 6513 x1394

www.invue.com

0 Kudos

1,288 Views
Sabina_Bruce
NXP Employee
NXP Employee

Hello Jeff,

Hope you are doing well.

I received confirmation regarding the original question. So, currently the ROM doesn't use all of the SRC_GPRn registers; however, there is potential future ROM patches or other RT parts that might use more of these registers. Essentially it is not recommended for use by customers to avoid having potential issues if the ROM is changed or if the customer decides to migrate to a different RT product.

The only exception is SRC_GPR5. This is one is allocated for customer use, you may write different values that could have an objective or meaning in your application. If the value remains through a reset , then you know the reset was a system reset or core lockup instead of a POR.

Hope it helps!

Sabina

-----------------------------------------------------------------------------------------------------------------------

Note: If this post answers your question, please click the Correct Answer button. Thank you!

----------------------------------------------------------------------------------------------------------------------- 

0 Kudos

1,288 Views
jeffthompson
Contributor V

Sabina,

I’m trying to save a value to SNVS->LPGPR[0], but not having any success. Immediately before attempting that, though, I do write set the NPSW_EN bit in SNVS->HPCOMR, and the Peripheral Explorer shows that write is successful, but not the one to SNVS->LPGPR[0]. Is there some other protection I need to remove?

Thanks,

Jeff Thompson | Senior Electrical Engineer-Firmware

+1 704 752 6513 x1394

www.invue.com

0 Kudos

1,288 Views
Sabina_Bruce
NXP Employee
NXP Employee

Hello Jeff,

Could you check the following:

1. CCM Clock Gating Register 5 is the snvs_lp clock enabled?

2. SNVS_HP Lock Register is GPR_SL set?

3. SNVS_LP Lock Register is GPR_HL set?

Note: When GPR_SL or GPR_HL bit is set, the register cannot be programmed.

If the above does not interfere with the proper setup then, please check section 20.5 of the reference manual specifically the steps to consider in "Initializing the LP section".

I've also found another post that resolves it by disabling the GPR_Z_DIS  bit. 

https://community.nxp.com/thread/478432 (Only the first response applies)

Let me know if this helps you.

Sabina

0 Kudos

1,288 Views
jeffthompson
Contributor V

Sabina,

  1. CCM Clock Gating Register 5 has the snvs_lp clock enabled
  2.  SNVS_HP Lock Register bit GPR_SL is not set
  3. SNVS_LP Lock Register bit GPR_HL is not set

I was trying this with the JLink debugger, so maybe the GPR_Z_DIS bit was preventing me from being able to R/W LPGPR.

Now that I've had time to reflect on this some more, I decided it would be better to not use MCU-specific registers. Instead, I've created a .noinit section of SDRAM where I can store variables that need to persist across warm reset. This technique is working out very nicely and is also much more portable than my previous attempt to pass a tiny amount of data between my boot and application.

0 Kudos

1,288 Views
jeffthompson
Contributor V

Thanks, Sabina. Based on your original answer, I’ve switched to using SNVS->LPGPR[0] and SNVS->LPGPR[1]. Shortly after my application starts running, I copy their values for subsequent use and then clear them. The application may sotre in them values to be used after a software reset and then reset using WDOG_TriggerSystemSoftwareReset( WDOG1).

Jeff Thompson | Senior Electrical Engineer-Firmware

+1 704 752 6513 x1394

www.invue.com

0 Kudos

1,288 Views
jeffthompson
Contributor V

Thanks, Sabina. The SNVS_LP general purpose registers are actually covered in section 19.4.2.1 of the document I have, which is “i.MX RT1060 Processor Reference Manual, Rev. 1, 12/2018”. Maybe you have a different version?

I don’t any access function in the SDK API reference manual, so do I just access them directly at 0x400d4100–0x400d400c?

Thanks again,

Jeff Thompson | Senior Electrical Engineer-Firmware

+1 704 752 6513 x1394

www.invue.com

0 Kudos