F29H850TU: Flash bank mode presents as BM0 in HS-KP

Hi Beat,

Let me look into the issue and get back to you.

Regards 
Arpit Varahmihir

Hello Arpit - have you been able to look into this?
Thanks,

Beat

Hi Beat,


1. Bank-mode encoding and register behavior 

BANKMODE register (offset 0x5C):

Reset value = 0x00000003 (Mode 0), this is the hardware reset default, independent of anything programmed in flash.
MODE field values: 0x3=Mode0, 0x6=Mode1, 0x9=Mode2, 0xC=Mode3 (matches your readback exactly).
Reset type: XRSn — i.e., this field is only reloaded on an XRSn/POR, never live.

TRM Section 8.4.1 F29H85x and F29P58x Real-Time Microcontrollers Technical Reference Manual (Rev. B) states this plainly: “The BANKMODE register is loaded from the BANKMGMT sector of the active code bank pair in FLC1 during device boot.” So BANKMODE is boot‑latched, full stop , nothing updates it mid-session.





2. Why BANKMGMT reads as access-denied in HS-KP 

TRM Section 9.8.1 (BANKMGMT Sectors) spells out the access rules directly:
SSUMODE1 / SSUMODE2: all code on any LINK can update BANKMGMT (full-debug zones enabled).
SSUMODE3: only the SECCFG update owner defined in SECCFG_UPDATE_CFG has permission to touch BANKMGMT, and SECCFG_UPDATE_CFG.UPDATE_EN must additionally be 0xC to enable BANKMGMT updates.




Now look at SECCFG_UPDATE_CFG (Section 9.17.2.16, offset 0x68) hardware reset values:

UPDATE_EN resets to 0x3 (“not enabled for flash updates — recommended”)
CPU_OWNER resets to 0x0 (CPU‑HSM)
LINK_OWNER resets to 0x2 (LINK2)
And SSUMODE itself (§9.17.2.3) resets to 0x00000003 = SSUMODE3.


So before a SECCFG image has ever been programmed (which only happens later, during Code Provisioning), the SSU sits at its hardware-reset defaults, SSUMODE3, with the BANKMGMT update owner defaulting to CPU‑HSM, not CPU1. Under SSUMODE3’s rule, your CPU1 application code is not the designated owner, so BANKMGMT access from CPU1 in HS‑KP returns 0 (access denied) which is why what you’re seeing at 0x10D80000/0x10D84000. This isn’t really “HS‑KP blocks bank mode” as a special case; it’s the SSU’s normal SSUMODE3 access-control behavior applying because no SECCFG has been loaded yet to relax it.


3. Since BANKMODE only reloads on XRSn/POR (never on the HS‑KP transition itself unless that transition happens to assert one), and since BANKMGMT is unreachable in HS‑KP under default SSUMODE3 ownership:

- Program BANKMGMT to Mode 2 (0x9) while still in HS‑FS.
- Issue an XRSn while still in HS‑FS and confirm BANKMODE reads 0x9 before proceeding , this is the only point at which the value actually gets latched.
- Only then run Key Provisioning into HS‑KP. BANKMODE will carry forward as whatever was latched at that last HS‑FS boot, since nothing reloads it again until the next XRSn.
- If it’s still reverting to 0x3, double check the XRSn was actually issued (and completed) between the BANKMGMT program and the KP step 

4.  determining pre-HS-KP bank mode from inside HS-KP:

Given Section 8.4.1 F29H85x and F29P58x Real-Time Microcontrollers Technical Reference Manual (Rev. B) and the XRSn-only reset behavior confirmed above: BANKMODE in HS‑KP is exactly the value latched at the boot that took the device into (or immediately preceded) HS‑KP, and it will not change again until the next XRSn/POR. So reading BANKMODE (0x3008005C) from inside HS‑KP does tell you the mode you’ll resume in once you leave HS‑KP provided the HS‑KP transition itself didn’t include an internal boot-ROM pass that reloaded BANKMODE from a BANKMGMT sector you hadn’t finished committing. I would need to follow up on the OTP Key Writer flow for this device with the expert and will get back to you.

Regards 

Arpit 

Hello Arpit,

Thank you for the reply, but it does not answer what I asked.

Point 1 repeats the BANKMODE encoding, which was not in question.

Point 3 describes exactly what I did, and the confirmed 0x9 reading in HS-FS was in my first post, taken immediately before the KP transition.

Point 2 assumes no security configuration had been programmed. That is not the case: before key provisioning this part had BANKMGMT committed to bank mode 2 and an active security configuration selecting SSUMODE1, which was TI's own default template. Both were verified in HS-FS. Furthermore, a device without a user configuration is also not in SSUMODE3. SPRADK2A §7.2 says units ship in SSUMODE1, my virgin part read SSU_MODE 0x30, and JTAG worked on it throughout. In SSUMODE3 debug ports would be closed and AP regions enforced.

Maybe it is helpful to explain What I am trying to achieve

1. Start with a factory device in HS-FS.
2. Session 1: set the flash bank mode and key provision, in one session.
3. Reset or power-cycle. The part is in HS-KP.
4. Session 2: program the application, CPU1 alone or CPU1 and CPU3, together with the security configuration, in one session.
5. Reset or power-cycle. The part is in HS-SE.

Step 4 is where I am stuck. In the test in Observation 2 the security configuration and the  CPU1 application did program inside one HS-KP session, but the CPU3 image was rejected (by the HSMrt). Since the device appears to be reverted into bank mode 0 while in HS-KP, and mode 0 has no CPU3 flash bank, the blocker is concerning CPU3 specifically.

What I measured

Three TMS320F29H850TU9 parts, REVID at 0x30180028 = 0x1.

Observation 1. The bank mode drops to mode 0 in HS-KP and comes back at HS-SE. 

Observation 2. In HS-KP the device actually runs in mode 0. In a controlled test I attempted programming one image holding the security configuration plus the CPU1 and CPU3 applications in a single HS-KP session. The security configuration and the whole CPU1 application programmed successfully, then the CPU3 certificate was rejected. The only difference between the two images CPU is the flash bank: CPU3 is FLC2, which is mapped to CPU3 only in bank mode 2. After the move to HS-SE the same image programmed both cores with no error.

Observation 3. The move out of HS-KP worked with a bank mode 0 security configuration on a part that was in bank mode 2 before it transitioned to KP. The device was successfully transitioned into SE by means of a mode 0 programming. Once in SE, the device magically returned to bank mode 2 and I was able to program CPU3.

Observation 4. Key provisioning does not appear to erase the security configuration or reset its counters. The counters cannot be read in HS-KP. Before key provisioning they were slot A 0xFFFFFFF3 and slot B 0xFFFFFFF4; after two later loads carrying a configuration they were 0xFFFFFFF1 and 0xFFFFFFF2, one decrement per load. A reset or erase would have restarted them at 0xFFFFFFFF.

Observation 5. In HS-KP, JTAG access worked and the SSU registers were readable. Only the BANKMGMT and SECCFG flash reads returned 0x00000000. If the device were running in SSUMODE3 here, I would not expect debug access at all without password unlock. 

This brings me to my specific Questions

Q1) Is the behavior in Observation 1 expected, and what causes it? Given Observation 5, the device does not appear to be in SSUMODE3 in HS-KP, so what blocks the flash reads and stops the boot ROM loading the bank mode from BANKMGMT?

Q2) Is it correct that CPU3 and FLC2 cannot be programmed in HS-KP, for the reason in Observation 2?

Q3) Is any valid security configuration write enough to move the device out of HS-KP, no matter which bank mode it was built for?

Q4) Is there any way to read the last HS-FS committed bank mode while in HS-KP, for example an HSM service or a boot ROM status field?

Q5) For step 2 above, is it supported to set a new bank mode and key provision in the same session with no reset in between? The order would be: commit the bank mode to BANKMGMT while still HS-FS, run the keywriter, then one reset. Will the new bank mode latch correctly once the part reaches HS-SE?

Q6) Does any of this change between boot ROM revisions or HSM runtime firmware versions?

Q7) Is the five step flow supported as written? If not, what is the recommended production sequence for a dual core part needing bank mode 2, CPU1 and CPU3 applications, and a security configuration?

Thank you, 

Beat

Hi,

CodeSkin said:

Is the behavior in Observation 1 expected, and what causes it? Given Observation 5, the device does not appear to be in SSUMODE3 in HS-KP, so what blocks the flash reads and stops the boot ROM loading the bank mode from BANKMGMT?

In HS-KP stage, the flash is not accessible by ROM. Thus it cannot see that the bank mgmt region has the bank mode 2 and hence the device is in bank mode 0 

CodeSkin said:

Is it correct that CPU3 and FLC2 cannot be programmed in HS-KP, for the reason in Observation 2?

In bank mode 0, there is no cpu 3 flash access, hence writing into cpu3 flash address wont work

CodeSkin said:

Is there any way to read the last HS-FS committed bank mode while in HS-KP, for example an HSM service or a boot ROM status field?

As I mentioned above, since C29 and HSM core has no flash access in HS-KP stage, it cannot see the last written bank mode in HS-KP stage

Allow me to get back with the rest of the answers

Thanks & Regards,

Aswin

Hello Aditya,

Thank you very much for the thorough and complete response.

And yes, I would be interested in receiving your modified code provisioning scripts.

Kind regards,

Beat

Hi Beat,

Could you send an email to me or let me know your email ID for external file sharing?

Thanks and Regards,
Aditya Singal