Is a Debugger Required to Install HSE Firmware on a New S32K310 Chip

[hyebin]

Hi,

I’m trying to install the HSE firmware on a new S32K310 chip.

When I connect a debugger (either Trace32 or PE Micro) and run the firmware step-by-step, the installation works fine. But if I simply load the ELF file and power-cycle the board (without a debugger connected), the code doesn’t seem to execute, and the HSE firmware is not installed.

Here are the methods I’ve tried:

1. Using Trace32 script and demo_security_installer project
    → Success

2. Modified demo_security_installer to not rely on the Trace32 script
    - With debugger attached and running the code → Success
    - Load ELF and power-cycle the board without debugger → Failure

3. Implemented custom PFLASH + UTEST enabling code and ran it using PE Micro
    → Success

4. Same as method 3, but only loaded ELF and power-cycled (no debugger attached)
    → Failure

This same issue also occurred when trying to program the ADKP key — it worked fine with a debugger connected, but failed when attempting to run the ELF alone after a power cycle.

So, my question is:
1. Is a debugger required to properly execute and install the HSE firmware or program keys (e.g., ADKP) on a fresh S32K310?
Or are there specific configurations (e.g., startup settings, boot mode, reset behavior, etc.) that must be done to make this work without a debugger?

Any insight or guidance would be greatly appreciated.
Thanks!

[lukaszadrapa]

Hi @hyebin 
The only thing which comes into my mind: Read-While-Write is supported only between partitions. One partition consist of one flash block. However, UTEST memory and flash block 0 are specific ones - they both belong to partition 0. That means: if UTEST is being programmed, the code cannot run from flash block 0. It must run from another block or from RAM.
HSE feature flag is in UTEST. When ADKP is programmed by HSE service, it is programmed to UTEST. So, this could be the root cause. Could you confirm where the code is running from? The behavior could be different if you just step the code in debugger.
Regards,
Lukas

[hyebin]

For code to run from RAM, I believe it’s necessary to copy the code from flash to RAM and also define the section in the linker file so that the function is stored and executed from RAM.

I’d like to know if there are any examples of this, or if there’s a detailed guide on how to do it properly.

In my current project, I’m using the RTD’s C40 module to implement flash operations, and I’m also working with HSE firmware.

[lukaszadrapa]

If you use C40 Ip layer, take a look at this thread:

https://community.nxp.com/t5/S32K/S32K344-C40-IP-Hardware-Fault-Problem/m-p/1697432/highlight/true

In Autosar MCAL layer, there's an option to load the flash access code to RAM automatically but it's not available in Ip layer. It's up to user to manage that when Ip layer is used. 

There's also general description how to move some code to RAM:

https://community.nxp.com/t5/S32-Design-Studio-Knowledge-Base/HOWTO-Run-a-routine-from-RAM-in-S32-De...

Regards,

Lukas

[hyebin]

hi.

I tried the method you suggested before, but it didn’t work.
So, I also tried the approach described in the following link, but that didn’t work either. [RTD400HF01 LLD]K312 No HSE secure debug operation - NXP Community

This project was set up according to the method in that link. This project was set up according to the method in that link, based on the C40_IP example, implementing the write of 0xAABBCCDDDDCCBBAA to the UTEST area HseFwEnable, and configuring it to execute from RAM.

It works when the debugger is connected, but it doesn’t run when the debugger is disconnected.

1. Could you take a look at this project and let me know what might be wrong?

2. My ultimate goal is to program a new S32K310 chip by loading a hex file, install the HSE firmware without relying on a debugger, and then load an application that utilizes SPI communication and HSE services.

Is there a minimal project template available that includes a properly configured linker script and startup files to support this workflow?

3. Additionally, in a typical production scenario for a product that leverages HSE firmware features on the S32K310, what is the standard approach to achieve this?

[lukaszadrapa]

1. The solution using MEM_43_INFLS_START_SEC_RAMCODE and MEM_43_INFLS_STOP_SEC_RAMCODE works. You just need to update this in both C40_Ip.c and C40_Ip.h files. You are not supposed to call MemInfls_AccessCodeLoadToRam() - this is internal function for MCAL layer.
Then notice that even in synchronous mode, the driver requires to poll for the result anyway. It's not blocking function. That means the code for polling must be forced to
RAM memory too. You can create a function which will initiate the programming and poll for result and force this function to RAM.

2. We provide only HSE Demo Examples:
https://www.nxp.com/webapp/Download?colCode=S32K3_HSE_DemoExamples
There's project for HSE installation:
c:\NXP\S32K3_HSE_DemoExamples_1_0_0\S32K3_HSE_DemoExamples\Device_Configuration\S32K344_HSE_FW_INSTALL\
It's up to users to create own solution.

3. If flash memory size is not an issue, you can link the HSE firmware directly to your application and use IVT installation method. This way, only one image needs to be flashed in production. If flash size is a concern, you must first flash a project that installs the HSE firmware (like S32K344_HSE_FW_INSTALL mentioned above), then delete it and flash your application.