AN-ISC-8-1207_Synchronization_Cry_Flss

Synchronization between AUTOSAR Cry and Fls
1
Introduction
AUTOSAR defines Crypto Driver (Cry) and Flash Driver (Fls) as MCAL modules for independent
hardware modules. But as the crypto module also provides key storage functionality, this is often
implemented in the microcontroller by using a shared flash unit. This can lead to race conditions, if
AUTOSAR Crypto Driver and Flash Driver are used concurrently.
No Synchronization
Crypto Driver
Flash Driver
Software
Hardware
Crypto Module
Flash Module
Race Condition
Flash Memory

Figure 1 - Race Condition During Flash Memory Access
This application note describes several synchronization methods and gives advice which method
should be applied. The synchronization itself must be implemented by the application during the
integration of the MICROSAR stack, as the used method depends on the system layout and
requirements.

Caution
The occurrence and effect of the race condition heavily depends on the used

microcontroller. Please double-check whether your specific hardware is affected and
confirm whether the methods described in this application note are applicable to your
system.

Caution
The examples in this application note are not thoroughly tested. The user must verify the

functionality for the intended use case. Vector´s liability shall be expressly excluded to the
extent admissible by law or statute.

1.1 Access Conflict Types
Table 1 lists possible access conflict types. In this application note, it is assumed that each of these
combinations will lead to a race condition and must be prevented. E.g. even if the Crypto driver
performs only a read access to the key (like MacVerify), a parallel read access of the flash driver to
the hardware is not allowed.
If the used microcontroller is less restrictive, a less restrictive synchronization scheme might be
applied. Such optimized synchronization scheme is not covered by this application note.
Copyright © 2017 - Vector Informatik GmbH
2
Contact Information: www.vector.com or +49-711-80 670-0

Synchronization between AUTOSAR Cry and Fls
Crypto Driver
Flash Driver
Conflict
Use Key (e.g. MacVerify, MacGenerate)
Read Flash Memory
Read / Read
Write Key (e.g. KeyElementSet)
Read Flash Memory
Write / Read
Use Key (e.g. MacVerify, MacGenerate)
Write Flash Memory
Read / Write
Write Key (e.g. KeyElementSet)
Write Flash Memory
Write / Write
Table 1 - Access Conflict Types
2
Use Case Description
The synchronization methods are discussed based on three different users of Crypto and Flash Driver.
Please adapt the described concepts in case of a different use case shall be implemented.

Caution
The described behavior of the Fls module is implementation-specific. Please confirm this

behavior for the used Fls module.

User
Functionality
Call context of hardware access
Nonvolatile Memory
Fls: Read and Write
Fls_MainFunction
SecOC
Cry: MAC Processing
SecOC_MainFunction
Key Management
Cry: Key Update
KM_MainFunction
Table 2 - Users of Crypto Driver and Flash Driver
The Fls is used asynchronously: the flash operation is started in Fls_MainFunction, but will be
finished later.
The Cry is used synchronously: the crypto hardware is idle after the execution of
SecOC_MainFunction and KM_MainFunction is completed.
asynchronous handling of Fls HW
Fls
Fls HW busy
Cry HW busy
conflict
Cry n
n
n
o
o
o
cti
cti
no Fls HW
cti
n
no
n
n
n
u
u
o
access in
u
F
cti
F
F
n
n
n
cti
this call
n
u
n
u
cycle
Mai
F
n
Mai
F
n
Mai
C_
C_
C_
O
O
O
s_Mail
s_Mai
Sec
F
Sec
lF
Sec
cycle time

Figure 2 - Conflict between Fls and Cry
3
Synchronization Methods of SecOC and Fls
This chapter describes synchronization methods between Fls and Cry for the SecOC use case.

Copyright © 2017 - Vector Informatik GmbH
3
Contact Information:   www.vector.com   or +49-711-80 670-0

Synchronization between AUTOSAR Cry and Fls
Caution
It is assumed that Fls_MainFunction cannot interrupt

SecOC_MainFunction. E.g. Fls_MainFunction is mapped to the same or a
lower priority OS task as SecOC_MainFunction.

Table 3 gives an overview and comparison of the different methods which are described in this
chapter.
Method  Characteristics
AUTOSAR Extensions
SecOC messages will not be sent during Fls
None
3.1
operation. Especially Fls erase might take a long
time.
3.2
Same as 3.1
Cry extension “Read Start” interface
Less impact on SecOC messages for “short” Fls
Fls extension “GetHWStatus”
3.3

operations
3.4
Difficult if Suspend/Resume needs a long time
Fls extension “Suspend/Resume”
Fls extensions “Suspend/Resume”
3.5
Most complex approach
and “asynchronous notification”
Table 3 – Comparison Matrix
3.1  Prevent Execution of SecOC_MainFunction
The current state of Fls can be polled by the function Fls_GetStatus. Therefore
SecOC_MainFunction should not be called in case Fls_GetStatus returns “busy”.

Caution
It is assumed that Fls_GetStatus can be called reentrant. Please confirm this behavior

for the used Fls module.

asynchronous handling of Fls HW
Fls
Fls HW busy
Cry HW busy
Cry n
s
n
o
u
o
cti
at
no Fls HW
cti
n
no
n
n
u
St
o
access in
u
F
cti
te
F
n
n
cti
this call
n
u
n
u
cycle
Mai
F
n
s_Gl
F
F
n
Mai
C_
C_
O
ck
O
s_Mai
e
l
s_Mai
Sec
F
Ch
lF
Sec
cycle time

Figure 3 - Prevent Execution of SecOC_MainFunction
Copyright © 2017 - Vector Informatik GmbH
4
Contact Information:   www.vector.com   or +49-711-80 670-0

Synchronization between AUTOSAR Cry and Fls
3.2  Prevent Execution of Cry Function
This approach is similar to chapter 3.1. But instead of preventing the execution of
SecOC_MainFunction, an API like Cry_XXX_DataFlashReadStart_Callout would be used.
With the API Cry_XXX_DataFlashReadStart_Callout, the read permission is checked by the
Cry driver: this shall be denied in case the Fls is busy.
The SecOC_MainFunction will retry with the next cyclic call, if the parameter
SecOCAuthenticationBuildAttempts in SecOC is set accordingly.

Note
The API Cry_XXX_DataFlashReadStart_Callout is not defined by AUTOSAR and

might not be available for your hardware.

3.3  Optimized Execution Prevention
The API Fls_GetStatus returns the status of the Fls driver. Whereas this is implementation-specific,
it might be only updated in context of Fls_MainFunction. Therefore it would report still “busy”,
whereas the operation in the Fls hardware might be already finished.
It is assumed an API like Fls_GetHWStatus is available, which reads the status of the Fls hardware
itself. An optimized version of methods in chapter 3.1 and chapter 3.2 can be applied in this case:
>
In task scheduling, SecOC_MainFunction is executed immediately before
Fls_MainFunction. Therefore the Fls operation from the previous Fls_MainFunction might
be already completed.
>
The API Fls_GetHWStatus is used instead of Fls_GetStatus

asynchronous handling of Fls HW
Fls
Fls HW busy
Fls HW busy
Cry HW busy
Cry
s
u
n
n
at
o
o
cti
cti
n
no
n
WSt
n
o
n
u
H
u
t
o
F
cti
F
cti
e
n
n
n
n
cti
u
u
n
u
Mai
F
F
n
s_G
Mai
l
n
F
F
n
C_
C_
O
O
ck
s_Mai
e
l
s_Mail
s_Mai
Sec
F
Sec
F
Ch
lF
cycle time

Figure 4 - Optimized Execution Prevention
With this approach, Cry handling is only skipped if the Fls needs a long processing time.
3.4  Interrupt Fls Operation
Some Fls drivers have a possibility to suspend and resume the current Fls operation. Such
functionality is used for this approach:
>
In task scheduling, SecOC_MainFunction is executed immediately before
Fls_MainFunction. Therefore the Fls operation from the previous Fls_MainFunction might
be already completed.
Copyright © 2017 - Vector Informatik GmbH
5
Contact Information:   www.vector.com   or +49-711-80 670-0

Synchronization between AUTOSAR Cry and Fls
>
In case Fls is busy: Fls operation is suspended before SecOC_MainFunction is called
>
If Fls operation was suspended: resume Fls operation after SecOC_MainFunction is completed
Fls
Fls suspended
Fls busy
Fls busy
Cry busy
Cry
n
n
o
o
cti
cti
n
no
n
no
u
u
F
cti
F
cti
n
n
d
n
e
n
u
n
u
Mai
F
F
n
Mai
n
spe
sum
C_
C_
e
O
O
s_Mail
s_Sul
s_Rl
s_Mail
Sec
F
F
Sec
F
F
cycle time

Figure 5 - Interrupt Fls Operation

Caution
The Fls_Suspend/Fls_Resume operation itself might need considerable time. This can

lead to issues, if a high call frequency of SecOC_MainFunction of Fls_MainFunction
is needed.

3.5 Asynchronous Operation of SecOC
In case Fls_Suspend/Fls_Resume needs a long processing time, a full-preemptive operating
system might be used during waiting time.
Appl
Task active
g
n
d
i
d
Cry
ss
shei
shei
ceo
fin
r

fin
d
on

p
d
n
e
cti
C
n
O
spe
u
ishe
F
sum
d
e
in
Su
n
f
n
i
e
R
Sec

r
:
:
g
e
pe
r
Ma
r
s
in
g
e
_
sum
e
s
g
g
g
g
C
s
i
e
i
gi
e
Tr
_Su
c
Tr
cO
s
e
s_Rl
Tr
o
Fl
S
F
Pr

Figure 6 - Asynchronous Operation of SecOC
SecOC_MainFunction is called by a separated extended OS task. Following example code
illustrates the concept.
Copyright © 2017 - Vector Informatik GmbH
6
Contact Information: www.vector.com or +49-711-80 670-0

Synchronization between AUTOSAR Cry and Fls
SecOC_Task:
While(TRUE){
  WaitEvent(Event_TriggerSecOC);
  If(FLS busy) {
  Fls_Suspend();
  suspended=true;
  WaitEvent(Event_SuspendFinished);
  ClearEvent(Event_SuspendFinished);
  }
  ClearEvent(Event_TriggerSecOC); //clear trigger
  SecOC_MainfunctionRx();
  SecOC_MainfunctionRx(); // call a 2nd time for verification retry
  SecOC_MainfunctionTx();
  If(suspended){
  Fls_Resume();
  WaitEvent(Event_ResumeFinished);
  ClearEvent(Event_ResumeFinished);
  suspended=false;
}}
The Fls must inform the SecOC_Task when Fls_Suspend/Fls_Resume is finished.
Suspend_Finished:
SetEvent(Event_SuspendFinished);
Resume_Finished:
SetEvent(Event_ResumeFinished);
The application can trigger SecOC_Task either cyclic, or only if SecOC processing is needed.
The transmission trigger can be obtained in following way.
ComIPduCallout: //get transmission condition – added for all secured messages in Com
SecOC_TxFlag=TRUE;
After call to Com_MainFunction:
Com_MainFunction();
if(SecOC_TxFlag){ // call this after Com_MainFunction
  SecOC_TxFlag=FALSE;
  SetEvent(Event_TriggerSecOC); //data of SecOC was prepared in Com
}
The reception trigger can be obtained in following way. Please make sure the CAN driver is operated
in interrupt mode.
CanGenericPrecopy: // enable “CanGenericPrecopy” feature in CAN driver
If(CANID=SecOCMessage CANID){
  SetEvent(Event_TriggerSecOC);
}
Copyright © 2017 - Vector Informatik GmbH
7
Contact Information:   www.vector.com   or +49-711-80 670-0

Synchronization between AUTOSAR Cry and Fls
The OS Event is set before the message data is transferred to SecOC. But the SecOC_Task is
activated only after the CAN ISR processing is finished due to OS priority handling.
4
Synchronization Method for Key Management
Synchronization between SecOC and Key Management is not needed, as both utilize the same Cry
driver. Therefore the Cry driver should take care of this synchronization.

Caution
It is assumed that Fls_MainFunction cannot interrupt KM_MainFunction. E.g.

Fls_MainFunction is mapped to the same or a lower priority OS task as
KM_MainFunction.

Synchronization of Key Management and Fls is less time critical than the synchronization between
SecOC and Fls. Therefore simpler methods as described in chapter 3.1 and chapter 3.2 can be
applied.
If chapter 3.2 is applied, a callback form Cry driver which queries the write permission should be used.
Such an API Cry_XXX_DataFlashWriteStart_Callout is implemented as an AUTOSAR
extension for some Cry drivers developed by Vector.
5
Contacts
For a full list with all Vector locations and addresses worldwide, please visit http://vector.com/contact/.

Copyright © 2017 - Vector Informatik GmbH
8
Contact Information: www.vector.com or +49-711-80 670-0

Document Outline

Last modified July 6, 2025: Initial commit (97b4320)