JTAG locking/unlocking in TRAVEO II CYT2B9 controller

[mayank_jena]

Hello,

I am trying to understand the JTAG locking / unlocking mechanism in CYT2B9, till now I have gathered the below information 

JTAG locking can be done when we are either in life cycle state NORMAL or SECURE

When we are in life cycle state Normal, we can configure SFLASH area(0x1700_1A00) to enable authenticated debug access, to write into SFLASH area we need to use Write-Row system call

When we are in life cycle state Secure, we can configure EFUSE bits to enable authenticated debug access, to write into EFUSE bits we need to use Transition to Secure system call

Both SFLASH/EFUSE bits are having similar structure, details of each bit can be found in the below snippets

SFLASH area

EFUSE bits

To enable authenticated debugging we need to set AP_CTL_xxx_DISABLE to “01” and SYS_AP_MPU_ENABLE to “0” either in SFLASH or EFUSE based upon life cycle state. Boot will make CPUSS_AP_CTL.SYS_DISABLE and CPUSS_AP_CTL.SYS_ENABLE to 0 disabling debugging access and will not configure SYS_AP_MPU.

To unlock JTAG we need to implement our own authentication logic and once successfully authenticated we can set CPUSS_AP_CTL.xx_ENABLE to “1“ to gain debugging access.

I have the below queries

1. As per TRM, debug access restrictions can be enabled and disabled in SFLASH area in NORMAL mode but in FAQ document it says once debug access is disabled, it cannot be enabled, see the below snippets for more information

            TRM  

          FAQ

   Whether SFLASH area is OTP or not?

2. Inter-processor communication (IPC) is one of the method to communicate the password to the HSM. For example, SYS_AP_MPU is enabled with limited access to only specific MMIO for IPC register, and minimal RAM to initiate IPC interrupt on HSM. After receiving the password, HSM validates it and, if correct, reconfigures SYS_AP_MPU to allow access for debugging

As per the above statement from FAQ, I understand that to provide the password to CM0+ core we need to use IPC mechanism, what is SYS_AP_MPU? as i didn’t found any information about it in TRM and what’s the purpose and usage of it during JTAG unlocking

3. What's the advantage of moving life cycle state "SECURE" if authenticated debug can be achieved in NORMAL state?

4. Write-Row API returns an error status when called during an active embedded operation? so when exactly we need to call this API i.e. during initialization or by checking any register status

Kindly help me to clarify above queries, Thanks!

[Ashish · Accepted solution]

Hi,

1) While EFuse is OTP, the SFlash is not OTP. It's reprogrammable (depending on device protection- in secure mode you cannot program it, but in normal- protection you can program/reprogram some limited rows using WriteRow system call api). But as far as NAR (normal access restriction) row is concerned, which will decide if your debugger can access the device or not (in normal protection)- the restriction can not be widened with WriteRow api. That is- if you set the bit for permanently disable to 1, then it will override enable bit, as a result you'll will not  be able to enable it again. If you set temporary disable - then still you cannot change it in SFlash to enable it (as it amounts to "widening of restriction", and WriteRow api will not allow that and will give error), but in this case, your application can still update the Access Port AP register of CPUSS to enable it, so if you have some kind of authentication based mechanism via CAN etc. already in place- you can enable the AP and debug-access should then be possible.

To clarify further-the Traveo-II device has typically 3  Access Port (APs)- CM0 AP, CM4/CM7 AP, System AP- each can be independently disabled. DAP (debug access port) tries to get the access to internal bus/registers and memory via the APs, so you can block this access using AP control bits. Each AP has 2 bits for debugger access control- Disable and Enable in CPUSS_AP_CTL register. If you set Disable bit of any Access Port (APs) to 1, it will block the Debugger to access AP and is permanent as it overrides enable bit. If you set Enable bit to 0 of any AP, it will also block the debugger but the application can overwrite it again to set Enable bit 1, so access is possible later- and this you can use for authenticated debugging implementation (i.e. debugger is blocked by default after boot based on NAR, but can be enabled later in application via some mechanism).In SFlash NAR row, you set  AP_CTL_xx_DISABLE bit-field, which is 2-bit- MSB correspond to CPUSS_AP_CTL.xx_DISABLE  and LSB corresponds to invert of CPUSS_AP_CTL.xx_ENABLE (as you can observe in table you gave). This value is applied during boot to the CPUSS_AP registers (in normal protection mode)- so for authentication mechanism implemented will have to be done after every reset/power cycle. 

2) As I told in (1)- there are 3 APs that can be used by debugger to get access of internal bus/registers/memory. While you can access most of things via any APs (there are some exceptions, like some private bus for CM0 can only be access via CM0 AP, but not via System AP or CM7/CM4 AP , and so on. ). So, for authenticated debugging or secure system, it doesn't make sense to enable all the APs. So, we can keep only System AP enabled with additional protection using MPUs (system AP can be further protected by MPUs)- and only limited access as needed to allow you implement authenticated debugging- this is already explained with details in FAQ document. After authentication is successful, the HSM can reconfigure MPU  to allow access for debugging . The implementation part- on how you want to implement authenticated debugging totally depends on you (e.g. one of the other approach can be via CAN, where you disable all the APs in NAR, but using some dedicated CAN message and some authentication, you can reenable one of the AP like system AP in your application to provide debugger access ). 

3) Secure system is not just about debugger access or implementing authenticated debugging, it's more than that. You also need to validate your application- to make sure it's not corrupted or modified by unauthorized methods. In the normal mode- the SFlash is still modifiable (not all but some rows), while in secure mode the SFlash is totally non-modifiable. The secure mode uses Secure_HASH which includes SFlash TOC2 and Public key for validating during boot, but normal mode uses Factory HASH for validation which does not include TOC2 and Public Key. You can goto RMA lifecycle for Failure analysis from Secure mode but not from Normal mode. In secure mode, it's expected that application is in CySAF (cypress secure) format. And there are other differences- kindly refer this application note- 

https://www.infineon.com/dgdl/Infineon-AN228680_Secure_System_Configuration_in_TRAVEO_T2G_Family-App...

Kindly note- you should not simply trigger to secure without making sure everything is taken care- else authentication may fail and you can't go to application.

Additional point- As we explained regarding NAR which is stored in SFlash- this restriction is only applied if your device is either in Normal_Provisioned or Secure_With_Debug life cycle. With Transistion_to_secure system call- which you can execute only once- this will move device lifecycle to Secure or Secure_with_debug (depending on parameter- whether you blow S fuse or D fuse)- and if it's Secure lifecycle, the SAR (secure access restriction) will be applied (which is stored in EFuse which you mentioned above). The boot code will apply this restriction either from NAR row in SFlash or SAR in Efuse during boot, depending on device lifecycle.  

4) At a time only one embedded operation (write/erase to flash) is expected to be performed by Flash controller - you can check for FLASHC_STATUS register- if it's busy. Active embedded operation would probably  indicate it's already busy. Also there are certain restrictions with using WriteRow api- kindly refer Architecture TRM- WriteRow section in Nonvolatile Memory Programming for details. 

Thanks,

Ashish