Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

TRAVEO™ T2G

Dmitriy_Chernov
Level 1
10 sign-ins 5 replies posted 5 sign-ins
Level 1

Hi,

I am working with CYT2B73CAD.

Can I protect memory from external reading (via debugger) without changing lifecycle state?

If this is not possible, then how to call the BlowFuseBit command from the program code?

And this is also not possible, then can I call BlowFuseBit command from J-Link or I need specific programmer for it?

Thanks.

0 Likes
1 Solution
Ashish
Moderator
Moderator 50 solutions authored 100 replies posted 100 sign-ins
Moderator

Hi ,

The address can be found in section 38.3.2 of TRM "Sflash Address Mapping". 

Ashish_0-1643025616853.png

Kindly note default values are as follow (first 4 byte for NAR, then for NDAR, rest are unused- as 0xFF):

Ashish_1-1643025701699.png

Thanks,

Ashish

 

View solution in original post

13 Replies
Ashish
Moderator
Moderator 50 solutions authored 100 replies posted 100 sign-ins
Moderator

Hi ,

It should be possible to control debug access in normal state (without changing lifecycle) i.e. block during normal access but re-enable after successful authentication. Kindly note that changing e-fuse is permanent and may not be reversed, so changing device life-cycle is non-reversible. You may refer the  KBA- Traveo II Automotive Body Controller - FAQ - KBA229757 , question- 12.3 which gives details on how to apply debug restrictions and perform authenticated debugging. Additionally you can refer section 32.2.1.1 "DAP Security" in Architecture TRM document of your device. 

Thanks,

Ashish

0 Likes
Dmitriy_Chernov
Level 1
10 sign-ins 5 replies posted 5 sign-ins
Level 1

Hi,

I tried to enable authentication debugging, but when I try to write to AP_CTL_xx_DISABLE,  CPUSS_AP_CTL.xx_ENABLE and CPUSS_AP_CTL.xx_DISABLE registers, the controller goes into hardfault. Maybe there is a special API for writing to these registers?

0 Likes
Ashish
Moderator
Moderator 50 solutions authored 100 replies posted 100 sign-ins
Moderator

Hi,

If you want to modify these bits (CPUSS_AP_CTL), then you need to program the row-13 , that is  NAR (normal access restriction) row of the SFlash via system call API- WriteRow (assuming your device is in NORMAL protection state). You may refer the section 33.4.25 in architecture TRM (doc number 002-19314) for details on this WriteRow api. Also refer the table 33-87 for the Access Restriction Encoding. This table gives you detailed explanation.

Note that this will modify the Sflash, but if you want to transition to secure state permanently- then you need to modify the e-fuse through TransitiontoSecure system call . Since this will modify the efuse bits, it is non-reversible. Refer section 33.4.24 for details on this.

Thanks,

Ashish

0 Likes
Dmitriy_Chernov
Level 1
10 sign-ins 5 replies posted 5 sign-ins
Level 1

Hi, 

If I want to program the row-13 of the SFlash via WriteRow API, should I pass SFLASH_USER_FREE_ROW013 or some other register as the address? I understand what API functions I should call, but I can’t find the address of the register I need (CPUSS_AP_CTL) in SFlash. Architecture TRM says the register I just needed (CPUSS_AP_CTL) is in row-13, but the address of this row-13 is not said. Where can I find this address?

Thanks.

0 Likes
Ashish
Moderator
Moderator 50 solutions authored 100 replies posted 100 sign-ins
Moderator

Hi ,

The address can be found in section 38.3.2 of TRM "Sflash Address Mapping". 

Ashish_0-1643025616853.png

Kindly note default values are as follow (first 4 byte for NAR, then for NDAR, rest are unused- as 0xFF):

Ashish_1-1643025701699.png

Thanks,

Ashish

 

Dmitriy_Chernov
Level 1
10 sign-ins 5 replies posted 5 sign-ins
Level 1

Hi,

Thanks for the reply, but my TRM ends with 34.3.5.5. Maybe I'm using an old version? (TRAVEO™ T2G  Automotive Body Controller Entry Family Architecture Technical Reference Manual (TRM) Document No. 002-19314 Rev. *H)

0 Likes
Ashish
Moderator
Moderator 50 solutions authored 100 replies posted 100 sign-ins
Moderator

Hi,

Your TRM document number and version is correct for Body entry part (CYT2Bxx), I took screenshot from the other document by mistake (for body high CYT4Bxx). But the SFlash address map is same in both cases, so the response is still valid.  Just refer section 34.3.2 "Sflash Address Mapping" instead of 38.3.2 (chapter name is "Flash Boot").

Thanks,

Ashish

Dmitriy_Chernov
Level 1
10 sign-ins 5 replies posted 5 sign-ins
Level 1

Hi,

Thanks for the answer, I managed to change the access restrictions in the flash by writing through the WriteRow() API at the address0x17001A00 the restrictions I need. But there is a new question: can I somehow reset these restrictions? When I try to write 0 through the WriteRow() API, I get error 0xF00000B1. In KBA-Traveo II Automotive Body Controller - FAQ - KBA229757 in question 12.3 it is written that it is impossible to turn access back on, but in TRM it is written that data in S-Flash can be overwritten. Which of these is true?

0 Likes
Ashish
Moderator
Moderator 50 solutions authored 100 replies posted 100 sign-ins
Moderator

Hi,

Access restrictions cannot be widen, means that if new restriction is narrower in this case (which you have done by "permanently" disabling AP), you can not reverse it back (to enable AP again). If you try to re-write this SFlash row to make newer restriction wider, then it will throw error. So effectively this disabling of debug access is permanent in your case. Please refer Following note from TRM:

Ashish_0-1643605451178.png

 

Regards,

Ashish

 

Dmitriy_Chernov
Level 1
10 sign-ins 5 replies posted 5 sign-ins
Level 1

Hi, 

Thanks for your reply. I was confused by this diagram:

Dmitriy_Chernov_0-1643609166637.png

It turns out that there is no way to enable the Debug AP access after it is turned off?

0 Likes
Ashish
Moderator
Moderator 50 solutions authored 100 replies posted 100 sign-ins
Moderator

Hi ,

Yes, if you have used "permanently disable AP" option , then it should not be reversible. If you have Not used "permanent disable AP" option, but rather just set disable AP option (e.g. AP_CTL_M0_DISABLE is set from 00->01 and not to 1x, similarly for other APs), then it's possible that it can be reversed.

 

Regards,

Ashish

0 Likes
Dmitriy_Chernov
Level 1
10 sign-ins 5 replies posted 5 sign-ins
Level 1

Hi, 

Maybe I don't understand something in this world, but it seems to me that I write 01 in AP_CTL_CM4_DISABLE 🙂

Dmitriy_Chernov_0-1643614446358.png

And if I try to write 0 - I get next error:  0xF00000B1.

0 Likes
Ashish
Moderator
Moderator 50 solutions authored 100 replies posted 100 sign-ins
Moderator

Hi,

I don't think your can directly enable this via debugger - as this would be "widening the restriction" and so it throws the error. There is a process of Authenticated debugging, which should be implemented so that you can have a process to enable debug access after providing proper authentication. The KBA which I referenced in my earlier response, in question 12.3 describes this process. Let me know if there  is still confusion.

Regards,

Ashish

0 Likes