Question Regarding Critical Section Protection for OTP and NVM Access Services

wodudwo

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?

lukaszadrapa

Conversely, is it also an issue if the application core performs a program/erase operation while HSE is already performing a program/erase operation?

- Yes, it is an issue because no more flash operations can run at the same time.

If so, can this situation be prevented by checking not only bits 21:16 but also bits 29:24 of the HSE_CONFIG_GPR3 register before the application core starts the program/erase operation?

- Yes. This would help in situation when HSE is already programming the flash and application core want to also start another flash operation.

If this approach is not sufficient to prevent such conflicts, would using a critical section be the recommended solution for protecting these service requests?

- When HSE performs mentioned NVM operations (catalog format, key import…), application should not start other flash operations and should not access flash block which is being programmed by HSE. If anything like that is done by the interrupt handlers, yes, critical section would prevent this conflict.

Additionally, the tables do not explicitly describe the case where the application core is executing code from a code flash block while HSE is performing a program/erase operation on the same code flash block.

Is this scenario considered safe without any synchronization, or does it also require some form of protection?

- Code flash memory is being programmed by HSE only when HSE/SBAF installs/updates/recovers/erases HSE firmware. This is done either out of reset automatically or it is triggered by software.

HSE firmware is located it the end of code flash (in FULL_MEM version) or at the end of active and passive block (AB_SWAP version). It is expected that the application starts from lower flash blocks and it also waits until initialization is done and until HSE finishes the initialization (and possible flash operations). So, there’s no risk in this case. If application triggers an update of HSE firmware, it’s up to user to ensure that corresponding flash block is not access during this operation.

If protection is required for this scenario, what would be the recommended way to implement it?

- As described above – after reset, do not access flash block which contains HSE firmware until initialization is completed. And do not access the flash block when your software initiates HSE firmware update.

View solution in original post

lukaszadrapa

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

wodudwo

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?

lukaszadrapa

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.

wodudwo

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?

lukaszadrapa

We are getting back to tables 149, 150 and 151 from HSE firmware reference manual which I mentioned earlier. It's necessary to evaluate the program flow, compare it with scenarios described in the tables and decide if countermeasures are needed or not. Otherwise there could be a risk that HSE will disrupt application core(s) or vice versa.