AM62A7: Question Regarding HS-SE Device Debug Port Unlock Methods

Dear customer, 

    Could you please refer the link here ?   Thanks. 

    https://software-dl.ti.com/tisci/esd/latest/6_topic_user_guides/secure_debug.html?highlight=jtag#secure-debug-user-guide

Regards,

Linjun

Hi Linjun,

Thanks for this doc. It answered the question regarding the certificate generating.

However, there are still 2 questions pending:

1. How to build SBL images with extended debug information.
2. How to permanently lock the debug port via eFuse.

Are there any specific guides on these processes?

Best Regards,

Yang

Even if  programming the eFuse debug port is supported, The CRP  (customer return process )  can't support for failure chips. Please note!

Hello,

For unlocking the HSM core, the previous method of enabling the debug extension cannot be used.

Instead, the JTAG unlocking of all the cores including HSM must be done through the following TISCI API described in the following section:

https://software-dl.ti.com/tisci/esd/latest/6_topic_user_guides/secure_debug.html?highlight=jtag#using-tisci-api

The latest MCU+ SDK has an example for this:

https://software-dl.ti.com/mcu-plus-sdk/esd/AM62AX/10_01_00_33/exports/docs/api_guide_am62ax/EXAMPLES_RUNTIME_DEBUG_UNLOCK.html

Regards,

Prashant

Hi Prashant,

I've tried this method using V9.2 SDK. I've changed the board config to allow a53 core to unlock JTAG, rebuilt boardcfg , libs and sbl. Then I flash and reboot the device and got this respond message from a53 core:

I connected the a53 core and found that the code got stuck here:

Something worth noticing is that when I rebuilt the boardcfg, It doesnt work for DEVICE_TYPE=HS. It only successfully generates files for DEVICE_TYPE=GP. Below is the error generated when building boardcfg if I changed the DEVICE_TYPE in the devconfig.mak from GP to HS.

What I have done then is that I first build boardcfg with DEVICE_TYPE set as GP, then I build boardcfg again with DEVICE_TYPE set as HS. This generates the sciclient_defaultBoardcfg_hexhs.bin.hs.signed file as shown below.

Then I repeated the rebuilt of libs and sbl. I re-flash the sbl stage 1 into the device and rebooted. However the phenomenon remains the same.

Please help to resolve this issue.

Regards,

Yang

Hi Prashant,

I've tried the same method using V10.1 SDK. The A53 core printed the following:

However I still can't connect the HSM core.

Referring to the this documentation here,

the debug_unlock_x509_cert_gen has been modified as follows:
.
The HSM should be able to be connected. How is it still not open to JTAG?

Can you prioritize this issue as enabling the HSM debug can help with all the other blocks we are encountering and this is a matter of urgent.

Regards,

Yang

Hi yang,

   Could you please modify the sciclient_defaultBoardcfg_security.c as below to try?

  .jtag_unlock_hosts = {TISCI_HOST_ID_A53_0, 0, 0, 0},

Linjun

Hi,

This method doesn't work either. Current phenomenon is that no matter how I change the sec_dbg string,  the only cores I can connect to are the A530-0 and DM-R5. Also, after I connected to the DM-R5, if I connect any of the other blocked cores, the DM-R5 automatically disconnects, and after this the DM-R5 couldn't be connected to either.

Also I noticed in the TISCI 10.01.08 document it says:

Does this apply to AM62Ax?

TI experts, please help with this issue.

Regards,

Yang

Hello,

Cesc Yang said:

Does this apply to AM62Ax?

That statement is for the TIFS core not the HSM core. The HSM core can be unlocked on the HSSE device.

Cesc Yang said:

However I still can't connect the HSM core.

Please share the error reported by debugger on connecting to the HSM core.

Thanks!

Hi Prashant,

Please refer to the image below:
This is how I modify the cert_gen.py:
;
These 2 cores are the ones that can actually be connected to:
;

This is the error shown if I try to connect to the HSM:

;

Additionally, if I try to connect to the MCU-R5 core, this would happen(The DM-R5 also gets blocked after about 2 seconds.):

Thank you very much for you support.

Regards,

Yang

Hi,

It seems like the MCU R5F core is not booted. Could you please share the full boot logs?

For testing purpose, could you please boot the default HSM appimage and see if you are able to connect to HSM core then?

Regards,

Prashant

Hi Prashant,

This is the flashing script I'm using. The HSM image is generated from the default HSM_min_sample.
;

This is the sbl and A53 print log(Uart No.1):

This is the DM print log(Uart No.3):

Uart No.2(Normally used by HSM trace) and Uart No.4(Normally used by MCU-R5) didnt print anything.

What does this mean?

Regards,

Yang

Hi,

After I switch these ipc example projects to helloworld projects, the cores can boot successfulIy, and as a result I can successfully connect to HSM and MCU-R5.

I'm going to try the same using SDK version the client's development is based on, which is SDK V9.2. If there's any issue I will update them here.

Thanks for pointing out the reason being MCU not getting booted here Prashant.

Regards,

Yang

Hi Prashant,

This method works, but only if I replace the makefile under mcu_plus_sdk\tools\sysfw\boardcfg from V9.2 into the one in SDK V10.1.

Regards,

Yang

Hi Prashant,

Understood. Is there any known issue on the functionality of the ipc example in the SDK since the problem was the MCU core did not get booted correctly running the ipc example?

Regards,

Yang

Hello,

There is no known issue related to IPC example.

I was able to successfully connect to the MCU core with the default IPC_RPMSG_ECHO examples.

Regards,

Prashant