Issue with SecOC related crypto operations during ongoing FEE/FLS Operation

KanthReddy — Mon, 30 Mar 2026 14:19:21 GMT

Dear NXP Support Team,

We are currently facing challenges with SecOC message related crypto operations in our system due to ongoing FEE/FLS operations and would like to seek your guidance on possible solutions.

Specifically, we observe that CSEC operations cannot be executed when FTFC is busy due to ongoing FLS/FEE operations (FTFC status = 0).

During FEE sector switching, the FTFC remains occupied due to physical sector erase operations, which take approximately 13–130 ms per one physical sector. (And Fee logical sector is 32KB)

As each logical sector consists of 8 physical sectors, this results in a significant blocking duration as FLS operation is atomic after CMD gets issued.

At the same time, our SecOC communication has the following timing constraints:

* Cyclic SecOC messages with a period of 10 ms
* Event-based SecOC messages with a minimum inter-arrival time of 20 ms

Due to the FTFC busy condition, we are unable to meet the required SecOC timing deadlines, leading to communication issues.

We would appreciate your input on the following points:

1. Is there a recommended approach to handle SecOC processing while FLS physical sector erase is ongoing? (or it could be a FLS multipstep write operation in general)
2. Are there any mechanisms or best practices to utilize the time between erasing two physical sectors for CSEC operations?
3. Is there any configuration or workaround available to mitigate this issue without requiring changes to the MCAL layer?

Any guidance, recommended design patterns, or reference implementations would be highly appreciated.

Info: Prioritized arbitration (i.e. SECOC_CRYPTO PRIO > FEE/FLS operations) seems only possible in theory as implications of suspending/cancelling FEE/Fls multistep and Garbage collection may have negative implications or side effects.

Thank you for your support.

Best Regards,

Lakshmi Kanth

Re: Issue with SecOC related crypto operations during ongoing FEE/FLS Operation

lukaszadrapa — Tue, 31 Mar 2026 10:55:39 GMT

Hi @KanthReddy

A suitable way to coordinate Fee/Fls operations with other timing‑sensitive software (such as cryptographic routines) is not directly defined by the AUTOSAR specifications. Even though the underlying flash module on the device supports a flash‑erase suspend mechanism at hardware level, this functionality is not exposed through AUTOSAR Fls or Fee drivers. AUTOSAR does not provide any API or configuration option to pause or temporarily interrupt an ongoing flash erase or program sequence. As a result, AUTOSAR leaves this coordination problem entirely to system integration. Given these limitations, the approach described below is probably the only practical and AUTOSAR‑compliant method for interleaving Fee operations with other tasks.

A typical Fee job runs in small incremental steps. Each step is triggered by calling the periodic main functions:

{

Fee_MainFunction();

Fls_MainFunction();

status = Fee_GetStatus();

} while (status != MEMIF_IDLE);

Every time these main functions are called, the Fee driver advances its internal state machine and may request Fls to perform exactly one atomic flash operation (for example, a small program or erase action). When that atomic action completes, Fls becomes idle again and waits for the next main‑function call to begin another step. Fee continues this sequence until the entire high‑level Fee job is complete, at which point Fee_GetStatus() transitions to MEMIF_IDLE.

It is important to understand that Fee_GetStatus() reports only whether the full Fee job is finished, not whether the current atomic flash step is done. During a multi‑step write or maintenance sequence, Fee_GetStatus() will remain BUSY or BUSY_INTERNAL for the entire duration.

If timing coordination with other software is needed (for example, to run routines that must avoid overlapping with flash programming), the correct AUTOSAR‑compliant way to detect when an atomic flash step has finished is to use Fls_GetStatus(). Fls is the module that actually executes and tracks each atomic flash operation. When Fls_GetStatus() returns FLS_IDLE, the previous flash step is fully complete and the driver is waiting for the next main‑function call. That idle moment is the safe window in which other timing‑sensitive tasks can run.

After these tasks complete, calling Fee_MainFunction() again will allow Fee to proceed with its next atomic step. This method remains fully compliant with AUTOSAR design rules, requires no direct hardware access, and preserves the integrity of Fee’s internal scheduling.

In summary:

Fee jobs consist of multiple atomic flash steps executed one by one.

Fee_GetStatus() becomes MEMIF_IDLE only when the entire Fee job is finished.

Fls_GetStatus() provides the fine‑grained information needed to detect when each individual atomic flash step has completed.

By running other software tasks only when Fls reports idle, and by controlling when Fee_MainFunction() is invoked, the application can safely interleave its own operations with Fee’s multi‑step flash activity.

Regards,

Lukas

topic Re: Issue with SecOC related crypto operations during ongoing FEE/FLS Operation in S32K

Issue with SecOC related crypto operations during ongoing FEE/FLS Operation

Re: Issue with SecOC related crypto operations during ongoing FEE/FLS Operation