Additional queries on JTAG locking/unlocking in TRAVEO II CYT2B9 controller

[mayank_jena]

Hello,

After going through the explanation for my queries for "JTAG locking/unlocking in TRAVEO II CYT2B9 controller"

I have below queries

1. The restrictions cannot be widened using write-row API, as per the explanation I understand that once I have set temporary disable, I cannot go back and enable it but is it possible to set this bit to permanently disable from temporary disable, similarly if I don’t set SYS_AP_MPU_ENABLE bit can I set it at later point of time via write row API
2. Kindly let me know if the HW mandates user to have an authentication mechanism once we set AP_CTL_xx_DISABLE bit to temporary disable, as per the FAQ and explanation I see that user needs to decide the authentication mechanism and if authentication is successful, we can set CPUSS_AP_CTL.xx_ENABLE but the user has option to set this bit without any authentication mechanism
3. From explanation in point 2, I understand that we should not temporarily disable AP_CTL_SYS_DISABLE and just protect the peripherals via MPU setting, kindly confirm if my understanding is correct
4. Once we set AP_CTL_xx_DISABLE, for debug port to be locked we need to do a power cycle, kindly confirm if my understanding is correct

Kindly help me to clarify above queries, Thanks!

Link to the earlier asked queries and explanation: Solved: JTAG locking/unlocking in TRAVEO II CYT2B9 control... - Infineon Developer Community

[Ashish · Accepted solution]

Hi ,

1) Yes, in Sflash- temporary disable to permanent disable is possible via WriteRow, but not vice-versa. Once you do permanent disable, you can't go back to temporary disable or enable. You can enable SYS_AP_MPU_ENABLE later (provided you have SFlash access, device is in normal protection). In short, widening of restriction is not possible, but narrowing is possible. 

2) I don't think there is any HW mandate- authentication mechanism is up to user, and they can do it without any authentication at all (but isn't that's the whole purpose to restrict debugger to only authorized access? if user sets this bit without authentication, then why to restrict this at all? - you can just leave it open). 

3) Yes this is one of the approaches, it depends on you how you want to implement. Note that if you disable all the access-port then it won't be possible to connect the debugger at all. So, you can keep System AP enabled with MPU protection, which will allow you to implement authentication mechanism. Alternative if you disable all AP and implement authentication via other communication protocol like CAN to enable any AP, then if you attach debugger- then precondition is that it should not issue any reset to connect it (i.e. attach to running target is possible, but as soon as reset it done it will get disconnected because SFlash NAR restriction will reapply)- that's why a better approach would be to have one AP enabled.  

4) Yes, if you are modifying SFlash, then power cycle will be necessary as setting gets updated after boot, but I don't think this is mandatory for CPU register (i.e. if you directly set it). I think in 1st point, 2nd para (of my previous response, in the link you referred)  I had highlighted how the operation takes place with respect to SFlash NAR row and CPU-AP control register and difference between two. 

Thanks,

Ashish