What exactly happens if the class b complementary check is interrupted?

[Chris-tian]

To protect variables in a class b application a redundant complementary variable is stored in a separate memory location. The idea is to check if the exclusive or of those 2 variables is 0xFF before using them. My question is what exactly happens if the comparison is interrupted and the value is changed in the meantime? Following is a short example:

1013           ; 374   if ((spl_state_u8 ^ spl_state_inv_u8) == 0xFFU)

1015 0287 b60c     ld a,L71_spl_state_u8

1016 0289 b80d     xor a,L12_spl_state_inv_u8

1017 028b a1ff     cp a,#255

1018 028d 2704ac2a032a jrne L134

The value L71_spl_state_u8 is loaded into register a (1015), then a hypothetical interrupt occurs which changes the value of L71_spl_state_u8 and the complementary value L12_spl_state_inv_u8. After the interrupt the register a is restored from the stack but the new value of L12_spl_state_inv_u8 is taken for comparison (1016). This will fail and the application will exit. Is my interpretation correct? Or did i miss something? Because that is exactly how the class b library is implemented by st.

[Jaroslav JANOS]

Hi @Christian Schäfer​ ,

why exactly would you change the control variables in some interrupt?

Or are you referring to this part of the Class B code, where the TimeBaseFlag variable is modified in the SysTick interrupt?

/* Verify Time base flag integrity (class B variable) */
if ((TimeBaseFlag ^ TimeBaseFlagInv) == 0xFFu)
{
...
}

If yes, then you can see in the example, that TimeBaseFlag can normally be only 0xAA (it is changed to this value in the ISR), or 0x0 (which is here normally not possible, due to the preceding if statement) and TimeBaseFlagInv is normally 0x55 (again, changed to this value in the ISR).

So until there is some corruption, then no, this won't fail.

BR,

Jaroslav

[Chris-tian]

Hello Jaroslav,

Thank you very much for your answer.

Your answer leads me to believe that there may have been a misunderstanding.

I would like to secure variables in the user code with this procedure. So it is not about variables from the ST Class B library. 

As far as I understand, the Class B Library only checks the functionality of the ram, but not the content, so that user variables still have to be secured? In this case, L71_spl_state_u8 and L12_spl_state_inv_u8 are user variables that can be changed by an interrupt.

Is this protection not necessary for user variables?

Greeting,

Christian

[Jaroslav JANOS]

Yes, I indeed misunderstood your question, sorry for that.

Yes, you are right, this library checks only the functionality of the SRAM, and if those variables are critical for your application, then they should be secured by yourself. Unfortunately I am not sure, if this protection is required for the certification, but I would strongly recommend it.

For the comparison, yes, your assumption is in this case correct...

BR,

Jaroslav

[Chris-tian]

Thank you for the clarification.

So I can avoid this problem by either disabling the interrupts or not letting the corresponding variable be written by the interrupt.

However, I have another question about this topic:

The variable to be used is checked by comparing it with the complementary variable. After this comparison, the content of the variable can be considered safe. What if between checking and using the variable corrupts? Then I have found this variable to be good although it no longer is. Doesn't the system become unsafe in this way?

[Jaroslav JANOS]

Hi again,

I discussed your questions with ST Class B expert, and I confirm that this usage of complementary memory is required and modifying this variable in the interrupt handler and reading it in the main program in parallel is not possible because of the atomicity problem you described. So yes, you have to either disable interrupts or modify the variable in the main program only.

To your latter question, yes, but you can never fully avoid such situation. To minimize the probability, shorten the time between checking and using it as much as possible.

BR,

Jaroslav