AM2634: Mcu_PerformReset is writing reserved bits

Hello QJ,

Can you provide a link for it?

Thanks

Hello,

This is the same version I have, not the one you added the screenshot from.

The API is not working as expected.

Also, in the MCAL no unlocking to CONTROLSS_CTRL before writing to the WARM_RESET_CONFIG.

This is done in the MCAL.

Abdelrhman Afifi said:

not the one you added the screenshot from.

The table is on page 217 of spruj42c.pdf

Hello,

This is page 217 

Abdelrhman Afifi said:

Also, in the MCAL no unlocking to CONTROLSS_CTRL before writing to the WARM_RESET_CONFIG.

This is a bug, it worked for me after unlocking.

I noticed that the WDOG0_RST_EN (bit 10~8) table is removed from the table "TOP_RCM_MSS_TOPRCM_WARM_RESET_CONFIG Registers" of spruj42C (revC).

Abdelrhman Afifi said:

Also, in the MCAL no unlocking to CONTROLSS_CTRL before writing to the WARM_RESET_CONFIG.

The function  SOC_controlModuleUnlockMMR(SOC_DOMAIN_ID_MAIN, TOP_RCM_PARTITION0); is to unlock the CONTROLSS_CTRL registers.

void SOC_controlModuleUnlockMMR(uint32_t domainId, uint32_t partition) is defined in soc.c in AM263x SDK.

Okay, is there an updated document?

QJ Wang said:

I noticed that the WDOG0_RST_EN (bit 10~8) table is removed from the table "TOP_RCM_MSS_TOPRCM_WARM_RESET_CONFIG Registers" of spruj42C (revC).

I did not get this: 

QJ Wang said:

The function  SOC_controlModuleUnlockMMR(SOC_DOMAIN_ID_MAIN, TOP_RCM_PARTITION0); is to unlock the CONTROLSS_CTRL registers.

void SOC_controlModuleUnlockMMR(uint32_t domainId, uint32_t partition) is defined in soc.c in AM263x SDK.

The functionality of the function is clear, it takes the related Register partition to be unlocked.

This unlocks the TOP RCM register before configuring the reset type to be executed.

The MCAL does not unlock the TOP RCM register before configuring the WARM_RESET_CONFIG register>

So, MCUPerformReset is not working.

The bit 8~10 of TOP_RCM_MSS_TOPRCM_WARM_RESET_CONFIG Register is RESERVED in the latest TRM. The screenshot I posted was from the previous version TRM.

Then what is the correct one?
And did you check the logic of the unlocking? 

Hi Afifi,

The table in the latest TRM is correct. 

EB Tresos on my machine stops generating the configuration files. I will check the generated code later. 

Hi Wang,

If the table in the latest TRM is correct, then the MCUPerformReset is writing to reserved bits, which is a bug.
Moreover, it is writing these bits without unlocking the lock register for the TOPRCM

Hi Abdelrhman,

Abdelrhman Afifi said:

Mcu_PerformSoftSysReset  is calling regWriteReadback(registerReadWrite_loca

The Mcu_PerformSoftSysReset() calls a register write function to write resetVal to &toprcmREG->WARM_RESET_REQ

Where resetVal = 0 for warm reset, and 1 for cold reset, M_zero=0, and M_Two=2:

Here is the description of WARM_RESET_REQ register:

Hello Wang, 

Thanks for your help. 

I am taking about MCUPerformReset API not Mcu_PerformSoftSysReset()

Hi Abdelrhman,

I knew it. Mcu_PerformSoftSysReset() is called in  Mcu_PerformReset() function.

Hello Wang,

Sorry, I forget to upload the attachment in the previous comment.


This is Mcu_PerformSoftSysReset() API, I am using MCAL version 00.09.00_07.

Hi Abdelrhman

MCAL_AM263x_00.09.00_07 is an old release. You are correct that It is a SW bug in 00.09.00.07 release and 08.06.02.01. This bug is fixed and the API is updated in MCAL_AM263x_AM273x_09.00.00.00.

Please download the latest version (09.00.00.00) from TI MySecureSW. The new API uses WARM_RESET_REQ instead of WARM_RESET_CONFIG to assert a war reset.

Bit[10:8] of WARM_RESET_CONFIG register is a RESERVED filed, and setting those bit doesn't assert a warm reset. 

Hello,

Can you provide the link for this newer MCAL?