HSE provides RSP_NOT_SUPPORTED response

[DGB]

Hi, I have an issue with HSE, for some reason seems it provides RSP_NOT_SUPPORTED (0xAA55A11EUL) response on each call (format key catalogues, verify cmac etc.). This happens when I use application together with bootloader on the ECU, so first bootloader starts and jumps to the application. Without bootloader, using only application seems that everything works. My suspicion is that there is a slight difference on clock/pll configuration/initialization between application and bootloader, does HSE verify it somehow? Does the clock change/reconfiguration may impact HSE somehow?

In both cases HSE status is the same: 0x0B60, which means that everything should be ok, but it's not. 

[Fane]

It's a cache problem, just disable Dcache when compile 

[lukaszadrapa]

Hi @DGB 

It's responsibility of user to provide correct clock configuration. HSE does not verify it and yes, wrong configuration may impact the HSE. Which device do you have exactly? Isn't that S32K312? Recently we found this problem:
S32K312 supports only clock “option B” as shown in Table 148 in the S32K3 reference manual (rev. 7). The table shows that HSE_CLK can be either 120MHz or 60MHz depending on the MC_CGM.MUX_0_DC_3[DIV] divider.
We just found out that it is possible to configure 120MHz HSE_CLK only during reset by DCF record. It cannot be done later by software for some reasons. That means it is necessary to set PLL_ENABLE in Boot Configuration Word, it is necessary to program crystal oscillator configuration flag in UTEST at 0x1B000050 (see section 32.4.3.2 in the S32K3 RM), it is necessary to program the dcf_client_utest_misc - HSE_CLK_MODE_AND_GSKT_CTRL needs to be 10 or 11. And finally – all this has effect only when secure boot is enabled (BOOT_SEQ = 1).
The documentation will be updated to reflect this and some SW support will be added to DEMO APP.
So, does your software configure 120MHz HSE_CLK? If so, try to set it to 60MHz only.

And next common issue - it's important to keep all descriptors/structures/variables used as input/output to/from HSE in non-cacheable region. It is shown in RTD examples how to do that. To check it, you can try to disable the data cache and you will see if it makes a difference.

Regards,
Lukas

[DGB]

Hi thank you for fast feedback. Yes it's S32K312, but I think it's not my case yet. HSE CLK is set to 60 Mhz on both sides, bootloader and application. And as I mentioned, only with application (IVT starts application directly) HSE is working fine, but when I flash both of them and flow is that IVT starts bootloader and then bootloader starts the application, HSE doesn't work at all, I observe not supported feature all the time as a HSE response, but the status of HSE seems to be correct, initialized OK. Maybe you could guide me which registers should I check in order to determine what is wrong from HSE point of view?

[lukaszadrapa]

What is the content of HSE GPR Register 3 at 0x4039C028?

And what about the data cache, did you try to disable it?

Regards,

Lukas

[DGB]

In 0x4039C028 register I have value 0xC1. According to data cache I removed D_CACHE_ENABLE flag from compiler defs, but I'm not sure if it's sufficient. Can I check in any register if data cache is still enabled?

[lukaszadrapa]

You can check DC bit in CCR core register. Maybe it's enabled later by software regardless of that definition.