Invalid Address Error when Trying to Generate RNG on S32K312

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Invalid Address Error when Trying to Generate RNG on S32K312

248 Views
kw3
Contributor I

I've created a simple application to create a random number based on examples on this forum.  Unfortunately, I always receive an 'HSE_SRV_RSP_INVALID_ADDR' response.  I've tried with the Hse_Ip drivers and the hse_host.h files and get the same results each time.  Cache is disabled.

If I modify the hse demoapp to create a random number, it works. I suspect the difference lays within the linker or startup assembly file, but I'm not sure.  I've tried searching this response, but didn't find anything related in the docs or forums.

#include "Mcal.h"
#include "hse_host.h"
#include "sys_init.h"
#include <string.h>
#include "S32K312.h"

static uint8_t muIf = 0U;         /* MU0 */
static uint8_t muChannelIdx = 1U; /* channel 1 */

hseSrvResponse_t getRandomNumReq(hseRngClass_t rngClass, uint32_t rngNumSize, uint8_t *rngNum)
{
	hseSrvResponse_t hseStatus = HSE_SRV_RSP_GENERAL_ERROR;

	hseGetRandomNumSrv_t *pGetRndSrv;
	hseSrvDescriptor_t *pHseSrvDesc  = &gHseSrvDesc[muIf][muChannelIdx];
	memset(pHseSrvDesc, 0, sizeof(hseSrvDescriptor_t));
	pHseSrvDesc->srvId = HSE_SRV_ID_GET_RANDOM_NUM;
	pGetRndSrv = &(pHseSrvDesc->hseSrv.getRandomNumReq);
	pGetRndSrv->rngClass = rngClass;
	pGetRndSrv->pRandomNum = (HOST_ADDR)rngNum;
	pGetRndSrv->randomNumLength = rngNumSize;

	hseStatus = HSE_Send(muIf, muChannelIdx, gSyncTxOption, pHseSrvDesc);
	return hseStatus;
}

int main(void)
{
	hseSrvResponse_t srvResponse = HSE_SRV_RSP_GENERAL_ERROR;
	uint8_t RandomNumber[16] = {0};

	while (HSE_STATUS_INIT_OK == 0);

	srvResponse = getRandomNumReq(HSE_RNG_CLASS_DRG3, 16, RandomNumber);
	while(srvResponse != HSE_SRV_RSP_OK);

	return 0;
}

/** @} */

 

0 Kudos
Reply
1 Reply

225 Views
lukaszadrapa
NXP TechSupport
NXP TechSupport

Hi @kw3 

Where is your stack? Is that forced to normal SRAM or to DTCM? If it is DTCM then HSE can't see these addresses. DTCM at 0x2000_0000 is visible only for core. Other bus masters can access DTCM of a core only via backdoor address at 0x2100_0000 (in case of core 0).

lukaszadrapa_0-1747725634426.png

So, it would be necessary to use backdoor address - add offset 0x0100_0000 to the address. Or better solution - ensure that all data objects used for communication with HSE are forced to normal SRAM.

If Autosar Crypto driver is used, there's an option to enable DTCM support. Crypto driver then automatically checks all the addresses and adds the offset if necessary. If Crypto driver is not used, it's up to user to manage that.

Regards,

Lukas

0 Kudos
Reply