Hi, We previously encountered an issue caused by a background process when modifying the OTP (Secure Debug Password) and Life Cycle (LC) in HSE_B.
As a result, we were advised to protect the OTP and LC update operations by using a critical section.
In addition, would it also be necessary to protect service requests that access the NVM area, rather than the OTP, such as ImportKey, FormatKeyCatalogs, SmrEntryInstall, and CrEntryInstall, by using a critical section?
Hi @lukaszadrapa,
thank you for your reply.
In that case, instead of entering a critical section, would it be sufficient to check the HSE_CONFIG_GPR3 register before accessing the flash to ensure that flash access is available?
Hi @wodudwo
To have full picture, I recommend to read description in HSE Firmware reference manual rev. 2.7 in section:
“14.6.5 Synchronizing flash read/write access between HSE and application core”:
https://www.nxp.com/webapp/sd/collateral/1765990353647716033651?version=2.7
There are tables 149, 150 and 151 where you can find details about typical scenarios.
In short: if HSE firmware is executing, it’s not possible to program a flash block from which the firmware is running from. In case of S32K344 and FULL_MEM version (just an example) it’s block 3, in case of AB_SWAP it’s block 1. It’s necessary to wait until HSE is in idle state and then do not trigger other HSE services.
If HSE is performing flash operation on SYS-IMG (like key catalog formatting, importing a key, writing NVM attribute…) then, in addition, it is not possible to access data flash memory.
If HSE is writing OTP data (attribute, life cycle advancing, programming password etc.) it is not possible to access UTEST and also flash block 0 because UTEST and flash block 0 are in the same read partition. And this seems to be the key point if you have a problem with ADKP programming and with life cycle advancing. Please take a look at this post where I described what needs to be relocated from flash block 0:
https://community.nxp.com/t5/S32K/S32K324-HSE-Setting-ADKP-Issue/m-p/2369325/highlight/true#M58774
And when talking about synchronization between flash and HSE, notice that the support for synchronization between FLS and CRYPTO modules in RTD was added in version 5.0.0 and higher.
Here is a screenshot from 6.0.0:
If you use older RTD version, it needs to be handled by users. Notice that this synchronization does not solve the problem with programming OTP attributes to UTEST. The code still needs to be relocated from flash block 0.
Regards,
Lukas
It depends on scenario.
“In addition, would it also be necessary to protect service requests that access the NVM area, rather than the OTP, such as ImportKey, FormatKeyCatalogs, SmrEntryInstall, and CrEntryInstall, by using a critical section?”
For this scenario – no. HSE_CONFIG_GPR3 informs users if read/execute or program/erase is blocked for application by HSE on some flash block. But this is not a protection similar to critical section in your code. Critical section will ensure that there will be no interrupt which could access data flash or which could somehow interfere with the operations. But this has nothing to do with status of HSE_CONFIG_GPR3.
Anyway, mentioned services like ImportKey, FormatKeyCatalogs, SmrEntryInstall, and CrEntryInstall are crucial configuration services which should be executed sequentially in controlled environment. It makes sense to use critical section. If it is necessary to handle some important interrupts in the meantime, it’s necessary to ensure that used interrupt resources does not interfere with HSE and flash blocks used by HSE.
Hi, @lukaszadrapa
Thank you for your explanation.
If I understand correctly, checking the HSE_CONFIG_GPR3 register alone is not sufficient, and protection using a critical section is still required.
My understanding is that even if an interrupt occurs, checking the HSE_CONFIG_GPR3 register before accessing the flash should prevent the application core and the HSE core from accessing the same flash block simultaneously.
If a critical section is not used, are there any other potential issues that could occur besides simultaneous flash access between the application core and the HSE core?