Hi Dear Colleagues,
My customer wants to enable the secure debug feature to protect the JTAG port from being red externally. They also hope that the secure debug feature can be enabled and disabled by ActivateSecureDebug() and DeactivateDebug() when the system receives commands from another device with higher priority.
According to AN12092, we can enable and disable Debug Interface Access by modifying DCF records, I thought the feature can be realized by the steps below:
1. Set the JTAG Password and passwords of the Password Groups;
2. Push the MCU's Lifecycle to OEM Production;
3. Call DeactiveSecureDebug() once the device receives the corresponding commands;
4. In DeactiveSecureDebug() - 1)Check the DBL bit of 4 Password Group; 2)If one of the 4 Password Group's DBL bit is set to 1, call PASS_DRV_UnlockPassgroup() to unlock the access to this Password Group, then set this DBL bit to 0
5. Use S32DS and PEMicro to debug the MCU, but it still requires JTAG Password;
In MPC5775E's Reference Manual, I found that:
According to the description, DBL bit can only be updated after a destructive reset, can I just say that it is impossible to realize the customer's requirement (enable the secure debug feature to protect the JTAG port from being red externally, and the secure debug feature can be enabled and disabled by ActivateSecureDebug() and DeactivateDebug() when the system receives commands from another device with higher priority) on MPC5775E?
Thanks.
Best Regards
Weiyou Wang
Hello,
My customer wants to enable the secure debug feature to protect the JTAG port from being red externally.
I am a bit confused here as you are referring to some SW routines of unspecified drivers.
So to make it clear in case of PASS module implementation you need to program DCF records to censor JTAG access. Once you have done it your device will behave as there is no JTAG module to external world until valid password is provided.
1. Set the JTAG Password and passwords of the Password Groups;
Yes
2. Push the MCU's Lifecycle to OEM Production;
Yes. After this you need to do destructive reset so the device will load changed DCF records during reset phase.
3. Call DeactiveSecureDebug() once the device receives the corresponding commands;
No idea what SW you are referring to. But once you censor the JTAG via PASS module, no SW will make change to fact, that you need to provide JTAG password in order to unlock JTAG module for debugging. Is it some MCAL driver?
4. In DeactiveSecureDebug() - 1)Check the DBL bit of 4 Password Group; 2)If one of the 4 Password Group's DBL bit is set to 1, call PASS_DRV_UnlockPassgroup() to unlock the access to this Password Group, then set this DBL bit to 0
Once you access the JTAG via providing correct censorship password, you will be able to connect to device. But you wont be able to modify the PASS module protected memory content until you provide valid PASS passwords into CIN registers.
Once you have done this, then you can read/modify flash with no restrictions from PASS module.
(enable the secure debug feature to protect the JTAG port from being red externally, and the secure debug feature can be enabled and disabled by ActivateSecureDebug() and DeactivateDebug() when the system receives commands from another device with higher priority) on MPC5775E?
If the supervisor unit can provide PASS passwords or clear DBL bit in PASS_LOCK3 for MPC5775 then it will be unlocked for configured masters.
I have no knowledge on function's headers you have posted.
Best regards,
Peter
Hi Peter,
DeactivateSecureDebug() and ActivateSecureDebug() are functions defined by the customer, let me show you what has the customer done:
1. Set the JTAG Password and passwords of the Password Groups
2. Set the DBL of LOCK3_PG0 to 1
3. If we want to enable debug interface access feature, there are 4 conditions that we need to meet: 1) Life cycle is in or after OEM Production 2) DCF Client - Censorship 3) Set JTAG Password 4) LOCK3_PG0[DBL=1]
Modify the Censorship DCF client:
4. Modify the Lifecycle:
After this step, the LC in SSCM is OEM Production, and the JTAG is locked, JTAG Password is required if the customer wants to debug with S32DS and Multilink.
5. In the customer's test code, once the MCU receives messages for unlocking JTAG, DeactivateSecureDebug() will be called, inside this function, the code will unlock the password group 0 first:
Then set LOCK3_PG0[DBL=0]
6. After step 5, the customer continues to use S32DS and Multilink to connect to the MCU, while, JTAG Password is still required. After entering JTAG Password, the customer finds that LOCK3_PG0[DBL=0].
Hello,
6. After step 5, the customer continues to use S32DS and Multilink to connect to the MCU, while, JTAG Password is still required. After entering JTAG Password, the customer finds that LOCK3_PG0[DBL=0].
This is correct according my knowledge. As you changes DBL bit and it will hold this value until next reset (or until you change it) where the DCFs are read and PASS and other modules are set according to DCFs.
Best regards,
Peter
Hi Peter,
Thank you for your reply.
To my understanding, once the DBL of LOCK3_PG0 is clear, the JTAG should be unlocked, while the customer tests the JTAG by debugging another project, JTAG password is still required in the Debug Configuration window. During the debugging, MCU will be reset by Multilink once, I guess this reset is not a destructive reset. If the customer executes a power-on reset, then connects the Multilink to the MCU, it shows that DBL bit of LOCK3_PG0 turns back to 1, which is consistent with the DCF records.
Best Regards
Hello,
As this is not directly express in the datasheet I will try to summarize it from what I understand.
It is not clear whenever external reset will restart the reset phase from the point where the DCFs are read.
But since this is common for other devices of this family, I expect that connecting the PE which has no hot attach feature like for example Lauterbach, will cause external reset to device.
Since I see the external reset time similar to the POR, I expect that the DBL bit will be set according to DCFs after you connect debugger.
Could you try it with Lauterbach attach feature?
Best regards,
Peter