AM2634: TCM Register and Bitfield Database Names Don't Match The Manual or Vice Versa

Hello Kier,

Reviewing the TRM vs the Register Addendum / XML file, it's pretty clear that the TRM register names are incorrect.

The Register Addendum is going to have the correct register names and you can search through it by using TCM as a search key to see the various TCM registers that are available. That will hopefully help you with getting a grasp for the concepts.

I will have to follow up with some team members next week to understand why the TRM is so far off base and what the right descriptions should be.

Kier said:

I managed to find one of them after some head scratching. CPUn_LOCZRAMA in the manual is actually LOCKZRAM_CPUn in the database. Is that correct?

I didn't see this register/bit field in the Register Addendum so I am not certain that is accurate.

Best Regards,

Ralph Jacobi

Hi Ralph,

Many thanks for the reply.

Ralph Jacobi said:

I didn't see this register/bit field in the Register Addendum so I am not certain that is accurate.

You're not certain which is accurate, the database or Reg Addendum?

I'm not sure either. I found LOCKZRAM_CPUn by guessing the search term and grepping the targetdb xml files:

From the register database point of view, the register which contains LOCKZRAM_CPUn is MSS_CTRL_R5SSx_INIT_TCM and is located at 0xD0. However, there is no register at 0xD0 and no mention of MSS_CTRL_R5SSx_INIT_TCM  in the Reg Addendum:

It seems plausible that this register and bitfield exist so this casts doubt on the completeness of the Reg Addendum too.

Ralph Jacobi said:

I will have to follow up with some team members next week

Thank you, appreciated.

Hi Ralph,

I found a reason for the missing items. They are terms used in the R5F TRM, not the AM263x TRM. Once I tracked down the R5F TRM: Cortex-R5 Technical Reference Manual r1p2 (arm.com) [1], I found the following:

CPUn_LOCZRAMA is in fact a pin on the Cortex processor, see page 395 of [1], but confusingly, not a pin on the AM2634.

ACTLR is the Auxiliary Control Register, see page 119 of [1]. 

The problem remains however: How can I check the value of these items, and others, in the CCS debugger? Are they monitorable and if they are, what are their aliases in the device register XMLs. If they are not monitorable, their mention should be removed from the AM263x TRM.

Another example.

None of the highlighted register names below in the AM263x TRM appear in the AM263x Reg Addendum. I believe the correct names are in red:

However, none of those register names, red or otherwise, appear in the register list in the debugger.

Hi Kier,

To give you some forewarning here, one of our primary owners for pulling these together is unavailable in the near term, so that will impede our ability to untangle this somewhat. May take a few days for something that would usually just be an hour to sort out.

Kier said:

You're not certain which is accurate, the database or Reg Addendum?

My confidence level is higher in the Register Addendum than the TRM as the RA and XML files are more tightly aligned and the XML files are what will give you fields to view in CCS.

Kier said:

From the register database point of view, the register which contains LOCKZRAM_CPUn is MSS_CTRL_R5SSx_INIT_TCM and is located at 0xD0. However, there is no register at 0xD0 and no mention of MSS_CTRL_R5SSx_INIT_TCM  in the Reg Addendum:

It seems plausible that this register and bitfield exist so this casts doubt on the completeness of the Reg Addendum too.

Frankly the incompleteness is not unusual here. There are often internal registers that are not exposed intentionally which is why there are gaps in the address ranges at times. What is unusual to me is this cross section with the Arm R5 TRM. I'll have to review how we typically map Arm R5 registers and present them.

I appreciate you calling these out so we can review these sections further and improve the quality of the AM263x TRM.

Best Regards,

Ralph Jacobi

Hello Kier,

I'll need to find out how to confirm my current set of assumptions but I believe this is what is going on thus far:

1) The details about LOCZRAMA were originally included to line up with the R5 TRM with anticipation that the feature would be included as part of the CTRLMMR register list.

2) Instead of making that field available to select, the architecture was changed to simply default to A = 0x00 as shown in Table 7-4 of the TRM.

3) The TRM only was updated to reflect the default value, but the ability to change it was not implemented.

One other reason that could explain this is that instead we have registers to set the RAM Start & End addresses. I need to find out next whether this works in conjunction with LOCZRAMA or not. If not, it might override the addressing of LOCZRAMA. How they work together is unclear to me currently.

Best Regards,

Ralph Jacobi

Many thanks for pursuing this Ralph.

Since this was started with just TCM in mind, I think I'll raise a separate ticket for the similar interrupts (PRU_ICSS) documentation problem I mentioned above. That one is bit more urgent.

Hi Kier,

Got it, I've picked up that thread as well as I have full background on the issues you've been having and have already pulled in an expert who has more knowledge about the PRU-ICSS chapter. We'll get you on update on that one later today and I'll aim to have full clarity on the TCM by Friday.

Best Regards,

Ralph Jacobi

Hello Kier,

I'm still awaiting some confirmation here, I will continue to follow-up with our design experts. I will provide another update Wednesday if I don't have a full answer sooner.

Best Regards,

Ralph Jacobi

Hello Kier,

I'm still waiting for confirmation on my assumptions on the architecture but I got the following feedback on how to access the registers. It requires using low level assembly code.

How to access these are given in the R5F TRM:

To access the BTCM Region Register, read or write CP15 with:

MRC p15, 0, <Rd>, c9, c1, 0 ; Read BTCM Region Register
MCR p15, 0, <Rd>, c9, c1, 0 ; Write BTCM Region Register

<Rd> here correspond to common CPU registers (R0, R1 etc)

The commonly used /needed APIs are usually implemented in startup code. However if not one can implement using above reference.

For example CSL_armR5PmuResetCycleCnt() API Reads the PMCR register. (See the code in C:\ti\mcu_plus_sdk_am263x_08_06_00_34\source\drivers\pmu\r5f\csl_arm_r5_pmu.S)

CSL_armR5PmuResetCycleCnt:
MRC p15, #0, r0, c9, c12, #0 /* Read PMCR */
ORR r0, r0, #(1<<2) /* Set C bit to reset the cycle counter, PMCCNTR, to zero */
MCR p15, #0, r0, c9, c12, #0 /* Write modified PMCR*/
BX lr

Best Regards,

Ralph Jacobi

Thank you very much Ralph. This is all valuable information.

Hello Ralph,

Understood, thank you.

By the way, I never intended to modify them, all I wanted to do was just check their value to understand the state of the SOC, a natural reaction to mentioning them in the TRM. I think rather than removing the section altogether, explain what the default state is are and mention that you don't recommend it being changed.

Kier.