ADKP Programming with HSE returning HSE_SRV_RSP_INVALID_PARAM

[Bhushan1312]

Hello Team,

I am trying to program ADKP using HSE FW installed on MCU, but getting HSE_SRV_RSP_INVALID_PARAM error.

Same sequence works well (HSE_SRV_RSP_OK) if i do Step-In using debugger inside HSE_ProgramAdkp() function.

I can read HSE FW Version, Auth mode without any issue.

Only for ADKP programming i am getting HSE_SRV_RSP_INVALID_PARAM error.

Attached is my Linker file. I have mapped all HSE variables to int_sram_no_cacheable region. Also, stack is mapped to int_sram_no_cacheable.  

Please let me know where its going wrong.

[Bhushan1312]

Hello @lukaszadrapa.

ADKP programming seems to be working with Linker changes (linker attached). As in previous linker i made too much of changes by mapping all data variables to SRAM section, also the stack was mapped to non-cacheable region.

I have not moved any of the functions to RAM or other flash section.

I am yet to confirm LC stage advancement. 

Thank You for your support.

[lukaszadrapa]

Hi @Bhushan1312 

Are you forcing HSE descriptors to DTCM?

DTCM memory at address 0x2000_0000 is visible only for core. Other bus masters can access DTCM only via backdoor addresses at 0x2100_0000. So, I do not recommend to use DTCM for HSE variables, use normal non-cacheable SRAM instead. 

And next point - when programming ADKP, be aware that this service programs UTEST memory. And that UTEST memory is in the same partition as flash block 0. That means the code should be executed from another flash block or from RAM. Otherwise it could lead to read-while-write errors. 

Regards,

Lukas

[Bhushan1312]

Hello @lukaszadrapa,

Thank you for the reply.

Yes, HSE descriptors are forced to DTCM and accessed same with offset as below:

Let me know if this is fine to work with.

For 2nd point: Do i need to move all the functions (given below) responsible for ADKP programming to other Flash Sector or RAM?

HSE_ProgramAdkp -> SetAttr -> HSE_Send -> Hse_Ip_ServiceRequest.

[lukaszadrapa · Accepted solution]

Yes, this approach is correct. The question is why you are getting HSE_SRV_RSP_INVALID_PARAM. I would step this down to the HSE_IP_ServiceRequest to check the HSE descriptor and address which is sent to MU. And I would try to disable the cache completely to see if it makes a difference. 

What to force to RAM:

HSE_IP_ServiceRequest – be aware that this function calls some other functions.

This is the critical part of code inside the function when using synchronous mode:

if (HSE_IP_REQTYPE_SYNC == pRequest->eReqType)

        {

            /* Convert from microseconds to ticks */

            u32TimeoutTicks = OsIf_MicrosToTicks(pRequest->u32Timeout, (OsIf_CounterType)HSE_IP_TIMEOUT_OSIF_COUNTER_TYPE);

            /* Send the service request to HSE */

            Mu_Ip_SetTxRegister(Hse_Ip_apMuBase[u8MuInstance], u8MuChannel, (uint32)pHseSrvDesc);

            /* Read the current value of the counter */

            u32CurrentTicks = OsIf_GetCounter((OsIf_CounterType)HSE_IP_TIMEOUT_OSIF_COUNTER_TYPE);

            /* Wait for the HSE response */

            while ((FALSE == Mu_Ip_IsResponseReady(Hse_Ip_apMuBase[u8MuInstance], u8MuChannel)) && (u32ElapsedTicks < u32TimeoutTicks))

            {

                /* Update the elapsed ticks, current ticks will be updated too by the OsIf function */

                u32ElapsedTicks += OsIf_GetElapsed(&u32CurrentTicks, (OsIf_CounterType)HSE_IP_TIMEOUT_OSIF_COUNTER_TYPE);

            }

The Mu_Ip… functions are inlined, so there’s no problem. But OsIf functions from BaseNXP module are not inlined, so you need to move them to RAM too. I recommend to step the function to see that all the code executed in this area is running from RAM. Or you can check the map file as well.

Regards,

Lukas