AM2634: Register Addendum and Database File for LOCK_STEP Info Could Be Wrong

Kier said:

a) "By default, after a device reset, both R5SS0 and R5SS1 are in lockstep."

After boot-up, it depends on the device initialization in SDL. If the LOCK_STEP of MSS_R5SSx_STATUS_REG is 0x1, the R5SSx is in lockstep mode, otherwise it is in dual-core mode.

Kier said:

Why does the Register View not show LOCK_STEP = 1 please?

The value in memory browser and register view should be consistent. Please refresh the contents of both windows 

QJ Wang said:

After boot-up, it depends on the device initialization in SDL.

What is the SDL please?

QJ Wang said:

The value in memory browser and register view should be consistent.

Quite. The question is why aren't they.

Update: Now I found the cause. The register definition (MSS_CTRL_MSS_CTRL.xml) contains a bug. The width element shown below is too small to capture Bit 8.

If this is increased to 16 then LOCK_STEP == 1. Ditto 'MSS_CTRL_R5SS1_STATUS_REG'.

Please correct the register xml for AM263 in CCS 12.7.

Sorry for my typo. I mean your SBL (secondary bootloader). If GEL files are used, please check which mode your R5SS in.

Kier said:

Update: Now I found the cause. The register definition (MSS_CTRL_MSS_CTRL.xml) contains a bug. The width element shown below is too small to capture Bit 8.

Great! Thank you, Kier. I will file a update ticket.

Thank you.

QJ Wang said:

If GEL files are used, please check which mode your R5SS in.

Yes, I'm using DevBoot with GEL files. So the only entities that could modify the LOCK_STEP flag from the silicon default are the RBL and GEL files.

If I set the following in AM263x.gel...

#define Enable_OnTarget_Connect 0

...then the GEL files will do nothing when the debug probe is connected.

After connection LOCK_STEP == 1 so it cannot be the GEL files changing this state from 0 to 1.

Are you saying it is the RBL modifying the LOCK_STEP value?

I think so. RBL run memory init, PBIST test, and select R5SS operating mode. 

I see, thank you.

In any case, I think for the Reset column in the Register Addendum to be useful it needs to reflect the value of the register at the earliest point where the user application has the opportunity to modify it.

Saying the Reset value of LOCK_STEP = 0 is largely irrelevant if the end user only ever sees LOCK_STEP = 1 after POR due RBL.

I'll raise a document feedback submission instead.

Hi Kier,

My understanding is that the value in "reset" column of register field description is the default value after PORz is de-asserted and before the RBL is executed.