Swap request: HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK via Hse_Ip_ServiceRequest returns 0xAA55A11E Hello, currently I am trying to perform an A/B swap on an S32K314HMS microcontroller. The swap is requested via: /* Reset the job status variable */ SwapJobStatus = SWAP_JOB_PENDING; /* Set the service descriptor for the HSE request */ swapHseSrvDescriptor.srvId = HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK; /* Set the request parameters to be sent to Hse Ip layer */ swapHseIpRequest.eReqType = HSE_IP_REQTYPE_ASYNC_POLL; swapHseIpRequest.u32Timeout = SWAP_TIMEOUT; swapHseIpRequest.pfCallback = SwapProcessMuChannelResponse; /* Send the service request to Hse Ip layer */ if (HSE_SRV_RSP_OK != Hse_Ip_ServiceRequest(SWAP_MU_INSTANCE, SWAP_MU_ADMIN_CHANNEL, &swapHseIpRequest, &swapHseSrvDescriptor)) { result = E_NOT_OK; } Then swapHseIpRequest.pfCallback (SwapProcessMuChannelResponse) will be reached and the returned HseResponse will be: static void SwapProcessMuChannelResponse( uint8 u8MuInstance, uint8 u8MuChannel, hseSrvResponse_t HseResponse, void* pCallbackParam ) { if (HseResponse == HSE_SRV_RSP_OK) { vFotaH_Appl_SwapJobStatus = SWAP_JOB_OK; } else { vFotaH_Appl_SwapJobStatus = SWAP_JOB_FAILED; VStdLib_ConvertUint32ToUint8ArrayBigEndian((uint32)HseResponse, DebugData); } } #define HSE_SRV_RSP_NOT_SUPPORTED ((hseSrvResponse_t)0xAA55A11EUL) /**< @brief The operation or feature not supported. */ This happens sporadically, sometimes the swap works as expected. What could be the reason ? Where can I find the reasons / scenarios when HSE responds with this return code ? This swap is triggered at the end of an update sequence, a couple of minutes after reset/power on (so HSE is 100% initialized). Re: Swap request: HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK via Hse_Ip_ServiceRequest returns 0xAA55A11E Hi @AlexI
This is very simple service with no parameters. The only explanation I have is that it is caused by data cache memory. Please make sure that the descriptor is placed in non-cacheable memory.
Generally, all data objects used for communication with HSE must be forced to non-cacheable memory because HSE can’t see the cache.
Probably not the reason in this case but: if DTCM memory is used, it’s necessary to use backdoor addresses. Normal addresses are visible only for a core which owns the memory. Other bus masters (other cores, DMA, HSE…) can see this memory only via backdoor addresses.
Regards,
Lukas
View full article