The default HSM firmware in the SDK is a dummy firmware that does not give any indication of whether it ran successfully or not.

If the HSM firmware is built from the HSM demo package and run, it outputs certain logs on the UART. However, the expected logs are not observed on any of the UART port indicating the firmware does not run successfully.

The built HSM firmware from the HSM demo package is attached.

Root cause

The issue is originating from the `Bootloader_socInitR5FAtcmBtcm` function called as part of the self loading of the DM firmware in Stage2.

This function writes the R5F vectors at the location 0x0

https://github.com/TexasInstruments/mcupsdk-core-k3/blob/k3_next/source/drivers/bootloader/soc/am62ax/bootloader_soc.c#L476-L476

This address is aliased to the HSM RAM base address (0x43C00000) at Stage2 which results in overwriting of the initial bytes of the loaded HSM firmware. This ultimately causes HSM firmware to crash at runtime.

Workaround

If the following patch is applied to skip loading the R5F vectors then the HSM firmware runs successfully and the expected logs are observed on one of the UART port.

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1499865/am62a7-r5f-atcm-address-conflict-corrupts-hsm-entry-point-in-am62a7-sdk-v10-01-00-33/5815435#5815435