This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MCU-PLUS-SDK-AM263PX: method to enable secure debug on R5F and HSM core

Part Number: MCU-PLUS-SDK-AM263PX

Tool/software:

I checked secure debug section in  "SPRUJ41_AM263xAM263Px_Security_Hardware_Addendum_19092024-1.pdf" document (HSM core data sheet for this target)

I have the following questions:

1- What is the purpose of debug authorization using SECAP? It will be good if there is a document which explain this.

2- I got that using debug configuration in SBL or HSMRunTime certificate can enable debug in SoC core but camn\t be used to enable debug on HSM core so How we can enable debug on HSM core ?

3- where can i found document which explain WIR procedure ?

Thanks

  • Hi,

    For 1 and 3. This procedure is only applicable for ROM, so it would not be used in a HSMRT scenario

    For 2, the below documentation would provide an idea on the ways to Open debug port on M4

    /cfs-file/__key/communityserver-discussions-components-files/908/Secure-debug-disable-options.pdf

    Thanks and Regards,

    Nikhil Dasan

  • - What do you mean by it is only applicable for ROM ? Do you mean ROM bootloader of R5F or M4 core ?

    If yes, It will be good if you provide document to explain this procedure also.

    - I checked the document you attached it\s very helpful. But I need to confirm some points?

    1- As I understand the HSMruntime image also has certificate which might contain debug extension so we will deal with HSMRuntime certificate in the same way we are dealing with debug extension of SBL certificate?

    2- DBG_FULL_ENABLE option can't be received in debug extension of certificates, Right?

    3- As I understand If no debug extension in certificates we can configure debug configurations during execution of HSM runtime image using HSMClient service.

    My question here is that can we trigger this service several times during the same power on cycle to change configurations several times?

    4- If no debug extension in certificates the debug will be disabled by default once HSMRunTime image executed ?

    4- what does it means by "The debug options set with TIFS is only applicable for the specific PORz and would reset back to JTAG disable in HS-SE device"?

  • - What do you mean by it is only applicable for ROM ? Do you mean ROM bootloader of R5F or M4 core ?

    If yes, It will be good if you provide document to explain this procedure also.

    Yes, the same is only applicable for HSM ROM, and is a procedure typically followed internal to TI. Let me align internally to clarify this confusion on the next version of HSM Addendum.

    1- As I understand the HSMruntime image also has certificate which might contain debug extension so we will deal with HSMRuntime certificate in the same way we are dealing with debug extension of SBL certificate?

    No, the debug extension passed into SBL certificate would only be accessed by HSM ROM to open debug for R5 core. During the loading of HSM RT, the debug extension in the HSM RT firmware is not checked by HSM ROM.

    DBG_FULL_ENABLE option can't be received in debug extension of certificates, Right?

    Correct, only R5 core debug can be enabled by ROM.

    - If no debug extension in certificates the debug will be disabled by default once HSMRunTime image executed ?

    Correct. It will be disabled in HS-SE device, until HSM services enable it during HSM RT

    - what does it means by "The debug options set with TIFS is only applicable for the specific PORz and would reset back to JTAG disable in HS-SE device"?

    This means that you can only use this service once per power cycle. These registers can only be written once per power cycle, Hence, it is necessary for HSM ROM to not touch these registers (i.e. no debug extension in SBL certificate) in order for HSMRT to configure the debug enablement (i.e. via service only once per Power cycle)

    Thanks and Regards,

    Nikhil Dasan