2393558_en-US

[#1]

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