HSE Development Based on S32K34

[qiuyanyi]

Hello, NXP experts!

         We encountered problems while implementing the function. Now we have implemented the SMR, CR, ADKP and RNG functions of HSE based on the official provided DemoAPI, but this is based on the default FIRC 48 MHz.

        Now we need to run the functions within the CPU system. Therefore, we configured Option A according to the documentation, with a Core speed of 160 MHz and an HSE speed of 80 MHz, as shown in the figure 1. 

        It was configured exactly according to the manual. However, the current result is that after the system clock is initialized, the HSE service no longer responds. The Get_Attr and Set_Attr functions keep waiting for a response, and the HSE will force a reset. Want to know what caused it and how to solve it?

[qiuyanyi]

@lukaszadrapa Hi Lukas,

Now there is a problem. My HSE service can operate normally when based on HSE-FW0_2_40_0, but it cannot work when using HSE-FW0_2_55_0. When generating the format key, it returns a 0xAA55A21C. The used SBAF is 0.5.0_0.15.0.6_pb230807. Are there any additional restrictions for FormatCatalogs in this version?

[qiuyanyi]

hi Lukas：
我现在使用RTD7.0.1时发生了一个问题，我使用MCAL的Crypto驱动格式化NVM秘钥目录的时候，请求IP SRV时返回AA55A11E，但是我使用HseLib_2.0资源库的HseFrm_Key_FormatCatalogs是成功的，所以我去排查的时候我看到资源库中的Srv函数传的描述符是在TCM中且地址转换函数也是在TCM范围内的。然而我Crypto驱动使用的描述符是在no_cacheable范围内的。所以现在有个疑惑，我在手册Table 155.中看到HSE的有效访问位置包含no_cacheable，这是怎么回事。
其中我还发生过一件事情，我在每次上电的时候都去擦除HSE NVMKEY时导致整个系统异常，首先是PLL一直不通过，后来我尝试多次复位后，时钟稳定了，但是HSE的状态异常，但是我直接看HSE GPR值是正常的，但当我禁用D-CACHE后就一切恢复正常了，这是怎么回事？

qiuyanyi_1-1779689096046.png

qiuyanyi_2-1779689137982.png

[lukaszadrapa]

All the data objects used for communication with HSE must be forced to non-cacheable memory. HSE can’t see the cache. If DTCM memory is used, the support must be enabled in Crypto driver by parameter CryptoEnableTCMSupport. That’s because HSE (as another bus master) can’t see TCM memories at the same addresses like the core. Only mirrored/backdoor address can be used (that’s what you can see in Table 155). Once enabled, Crypto driver checks all used addresses and it adds an offset to redirect the access to backdoor space when necessary.

I guess that there’s no problem with the SRAM or DTCM but rather with the configuration of catalogs. Could you share the configuration?

Regarding the second issue – I would need more details to be able to provide some help. If disabling of data cache helps, we are getting back to my explanation above. Make sure that all data used for communication with HSE are in non-cacheable memory and that TCM support is enabled in Crypto driver.

Regards,

Lukas

[qiuyanyi]

qiuyanyi_0-1779775790535.jpegqiuyanyi_1-1779775975597.jpeg

qiuyanyi_2-1779775981554.jpeg

qiuyanyi_3-1779776445198.jpeg

qiuyanyi_4-1779776449119.jpeg

qiuyanyi_5-1779776655337.jpeg

Hi，

       Regarding the second question, if it happens again, I will save the data. Now let's discuss the memory issue. For example, when I was conducting the request integrity check FEED, as shown in Figure 1, I defined the descriptor in the "no-cacheable" section. Then I went to debug as shown in Figure 2, and the memory location was correct, but as shown in Figure 3, the service failed. I conducted another test. As shown in Figure 4, I defined the dtcm segment. As shown in Figure 5, it is possible to pass. I can understand this. In RTDHse_ip.c, I used Hse_Ip_ToAHBAddress to perform an offset to obtain the modified address as shown in Figure 6.
So here I don't understand why I can't use it in the "no-cacheable" section.

[qiuyanyi]

qiuyanyi_0-1779787237403.jpegqiuyanyi_1-1779787241604.jpeg

At the same time, I also tested switching to "no_cacheable" using HseLib2.0, but it still couldn't be used. At present, it seems that the only option is to run the service within the DTCM block.

[lukaszadrapa · Accepted solution]

Hi @qiuyanyi 

I can see nothing wrong in that code. Isn't that a problem with the no-cacheable section? Could you try to disable data cache completely before running this code? 

Regards,

Lukas

[qiuyanyi]

hi,
I have now fully understood the principle of this content and the problem has been resolved. Once again, I would like to express my gratitude for your help! Let's discuss any further questions later.

[lukaszadrapa]

Hi @qiuyanyi 

Which RTD version is used? Isn’t that some older one? Why I’m asking: When changing HSE_CLOCK, HSE must be in idle state. It is not possible to change the clock while HSE is running. This can lead to unpredictable behavior. It is explicitly mentioned in the S32K3 reference manual:

“Before configuring HSE_CLK, you must wait for the SBAF to enter WFI by reading core status register of HSE CPU (PRTN0_CORE2_STAT).”

This was implemented to RTD version 5.0.0 and higher. If you have older version, it’s up to user to poll the WFI before clock initialization. So, this may be the reason why it is failing.

And next thing - isn't that just data cache issue? Did you try to disable data cache in that project? 

Regards,

Lukas

[qiuyanyi]

hi Lukas：
Then I plan to upgrade the RTD to version 7.0.0 or 7.0.1. Regarding this version, what are the key points to note for HSE development or are there any reference DEMO examples based on this version for HSE development?

[lukaszadrapa]

Hi @qiuyanyi 

I'm sorry for delayed response, I didn't get notification for some reason. 

In 7.x.x, there's no such problem with the clocks. These versions just do not contain Crypto driver in the main 7.0.0 or 7.0.1 release, so it is necessary to install additional package as described here:

https://community.nxp.com/t5/S32K/Crypto-43-HSE-Driver-for-S32K3-RTD-7-0-0/m-p/2319462/highlight/tru...

Regards,

Lukas