S32K388 HSE No Response Error

[darknite2023]

Hi.

I am running HSE FW 2.49.0 on my S32K388 devkit. HSE initializes without issues and Hse_Ip_GetHseStatus() returns:

> hse -s
HSE Status (0x960):
- RNG Init successful
- Host Debugger enabled + active
- HSE Init successful

However, a service request to read HSE FW info or a request for a random number errors out with "no response (bb55bb55)" and the system then resets and reset cause is reported as HSE SWT Timeout! All HSE related variables are mapped into non cacheable region of memory. The same code works fine on my S32K358 dev kit running HSE FW 2.40.0.

My projects are non autosar.

I have checked HSE FW 2.49.0 release notes for S32K388 as well the reference manual and found no pertaining errata.

It would be great if someone could shed some light on why this is not work or might be failing?

Thanks.

[lukaszadrapa]

Hi @darknite2023 

I have S32K388 EVB here with HSE firmware 2.49.0 FULL_MEM version installed. I have no problem to generate random number.

Can you share your project? Please provide built project with elf file. I can check it on my side.

Regards,

Lukas

[darknite2023]

Hi @lukaszadrapa.

Thanks for response. My project contains a lot of proprietary code that I will need to clean before I can share it and it will take me a day or 2 to get that done. While I am happy to do that, was wondering if you could provide/share your project that works? Thanks in advance.

Regards.

[lukaszadrapa]

I tested it in very minimalist and quick way without any project, just by using a debugger.

I simply created own descriptor (hseSrvDescriptor_t) in RAM memory like this:

lukaszadrapa_0-1746006796579.png

First word 0x300 is ID of HSE_SRV_ID_GET_RANDOM_NUM, second word is reserved and then there's hseGetRandomNumSrv_t structure. You can take a look at HSE service API reference manual. First word selects DRG3 class, second word selects length of random number (16 bytes) and last word sets pointer where HSE will write the random number.

Then I trigger the service by writing address of the descriptor (0x20400000) to transmit register TR[1] in MU_0. The result is that receive register RR[1] contains return value from HSE 0x55A5AA33 which is HSE_SRV_RSP_OK (operation was successful) and random number is available at 0x2040050:

lukaszadrapa_1-1746007122722.png

So, I'm sure the HSE_SRV_ID_GET_RANDOM_NUM works as expected regardless of drivers, software, etc. 

The data cache must be disabled for this test, of course.

lukaszadrapa_2-1746007518978.png

Regards,

Lukas

[darknite2023]

Hi @lukaszadrapa.

Attached, please find my project that attempts to request a random number from the HSE and it keeps failing. Please let know where I went wrong. Thanks.

Regards/

[lukaszadrapa · Accepted solution]

The code is correct, it's caused by clocks. I can see that you are using clock option A. In this case, it's necessary to program new DCF record to UTEST to change HSE_CLK_MODE_AND_GSKT_CTRL. This will ensure that internal clocks are correctly synchronized.

You can find file S32K3xx_DCF_clients.xlxs in S32K3 reference manual.

And you can find there that dcf_client_utest_misc contains HSE_CLK_MODE_AND_GSKT_CTRL which can have following values:

lukaszadrapa_0-1746190379596.png

So, it must be set to 1x. It is not default value, so we need to reprogram it.

Here is a screenshot from my debugger where I already added new DCF record:

lukaszadrapa_1-1746190536855.png

The yellow record is original record programmed in factory. I programmed new record (in red) on first available address where I changed  HSE_CLK_MODE_AND_GSKT_CTRL accordingly. And then the RNG service works as expected.

You can use attached script to program the record. Just check if 0x1B000770 is first available position in your UTEST.

Or next option is to program the record by your application.

Regards,

Lukas

[darknite2023]

Hi @lukaszadrapa.

Thanks for the quick response. Will the same solution be needed for my S32K358 board which I have configured to run in A clocking configuration as well? Thanks in advance.

[lukaszadrapa]

It's not needed in case of clock option A on S32K358 because it is default state:

lukaszadrapa_0-1746421171913.png

Regards,

Lukas

[darknite2023]

Hi @lukaszadrapa.
Thanks for the quick response and clarifying that a similar change is not needed on S32K358.
After programming the DCF record with the value provided by you, HSE services are no longer timing out on S32K388. Many thanks.