AURIX™ Forum Discussions

[User9635]

Hello Support,
In Aurix 2G, TriCore Core 0 is by default starts execution from Power On Reset.
Then through User Software, other TriCore CPU Cores can be started.
Is there any UCB configuration possible to start Cortex-M3 HSM Core in a similar manner from TriCore Core 0 from Power On Reset, so that the device will not become Brick under any error during development cycle?
Best Regards

[Harvey]

UCB_HSMCOTP0/1_ORIG and UCB_HSMCOTP0/1_COPY is related to HSM enabling/disabling

The SSW(Start up Software) boots the HSM module (i.e. HSM executes its firmware) when the field DMU_SP_PROCONHSMCFG.HSMBOOTEN is set.
Field : HSMBOOTEN
0 - HSM Boot is not enabled
1 - HSM Boot is enabled

In case of enabled HSM, SSW check below 3 contents
– check if ECC error occurred
– check that stack pointer points into internal RAM
– check that reset vector points into a valid HSM PFlash sector (sector HSM0X to HSM39X).

If there is no valid code in HSM PFlash sectors, MCU will be locked. at that time, there is no recovery method.

So, user have to program valid HSM code in HSM PFlash sectors. And then, user have to enable HSM

[User9635]

Hello Support,
Is there any way to check during run-time from TriCore CORE0 whether the following checks are satisfied while DMU_SP_PROCONHSMCFG.HSMBOOTEN=0
"
In case of enabled HSM, SSW check below 3 contents
– check if ECC error occurred
– check that stack pointer points into internal RAM
– check that reset vector points into a valid HSM PFlash sector (sector HSM0X to HSM39X).
"
Which flag within the device end-user can check to satisfy the above three conditions before making HSMBOOTEN=1?
Or, SSW never checks those conditions until and unless end-user makes HSMBOOTEN=1?

Best Regards

[cwunder]

baexps_pr1 wrote:
Is there any way to check during run-time from TriCore CORE0 whether the following checks are satisfied while DMU_SP_PROCONHSMCFG.HSMBOOTEN=0

No, the user is responsible for the correct UCB settings (that are stored in the Data Flash), including that they are in a "Confirmed" state for production. This would prevents any further modification to the UCB (essentially making it OTP).

You need to make sure that the HSM code is correct and available in the program flash where you have configured it to be enabled. The SSW will not have an issue if all the necessary steps are followed with an enabled HSM.

If you are worried during development about not having valid HSM code you can setup two HSM images and only work on one HSM image (so the other image is a backup). If you use Lauterbach for the debugger you can change the cmm files such that the second HSM image is a NOP function for that flash sector. You can also open up a memory window for the HSM code and make sure you never issue a reset if the HSM image is not present (i.e. when you update the code).

[User9635]

Hello Support,
According to the previous response :
"– check that reset vector points into a valid HSM PFlash sector (sector HSM0X to HSM39X)."
So SSW will get stuck and not jump to Core 0 User Code under the above failure mode.
How the end user will obtain the following error code [0xF002] ROM Firmware called BOS as shown below from HSM Target Spec Rev 2.0 for Aurix 2G?

Best Regards

[Harvey]

How the end user will obtain the following error code [0xF002] ROM Firmware called BOS as shown below from HSM Target Spec Rev 2.0 for Aurix 2G?

Answer : User can't obtain [0xF002]. This value can be obtained during SSW operation. Not user code operation.
During SSW operation, if user OS reset vector or stack pointer is invalid, STATUS_CODE is updated as 0xF002 and then, MCU go to sleep (Locked Status).
In other words, it is explanation related to internal SSW operation between Tricore SSW and HSM SSW. it is just information for user to understand internal SSW sequence.

[User9635]

Hello Support,
Please confirm if foreground secure boot means SSWWAIT=1
and
background secure boot means SSWWAIT=0
as shown below:

Best Regards

[User21811]

May i get this User Manual link?

[Harvey]

SSWWAIT is not related to this topic.
SSWWAIT is configuration for secure boot operation.

Secure boot means that check Tricore code integrity from HSM. Not HSM code.
Generally, HSM code is not checked because we assume that HSM code is already stored in secured Flash area

So,
If SSWWAIT set "1", Tricore SSW will jump after finish secure boot operation even though Tricore SSW sequence finish (Foreground secure boot)
If SSWWAIT set "0", Tricore SSW will operate in parallel secure boot operation on HSM (Background secure boot)