What version of STM32-XCUBE-CLASSB should i use for stm32f412CGUx, project under STM32CubeIDE IDE Version: 1.10.1.

[AMukh.3]

I wan't to add self tests for my project using your STM32-XCUBE-CLASSB library.

[AMukh.3]

I've tried to debug it with instruction stepping and disassembly: here is what i've got

i'm dropping on str r3, [r7, #4]

what i believe must mean to store the register r3(4096), on address offset base- r7(7), address offset value 4

kinda strange address and value, don't know where to proceed with debugging, maybe you can help?

i've attached pictures of disassembly, gen registers and macro that is in fact called in code

[Petr Sladecek]

As I've already highlighted, the problem is great probably at not preserved cpu registers corrupted during cpu startup test (the latest versions of compilers rely on their content despite all optimizations are switched off).

Of course, the Cortex M0 has limited set of instructions (reg list is limited up to R7). What about trick during safe/restore of r8-r11:

  PUSH {R4-R7}       ; Safe critical registers

  MOV R4,R8

  MOV R5,R9

  MOV R6,R10

  MOV R7,R11

  PUSH {R4-R7}

Rgds,

Petr

[AMukh.3]

Disabling STL_StartUpCPUTest leads to success in running all further test procedures on Nucleo-L053 example (CLASSB lib ver 2.2.0)

[AMukh.3]

Idk how to get rid of this problem on Nucleo-L053 example, so i just disabled STL_StartUpCPUTest and in helped to success in running all further test procedures, whta i was needed.

Because on F412, this test behavior is different.

[AMukh.3]

@Petr Sladecek​ now i'm facing another issue on my main CubeIDE project on F412, where i'm trying to integrate the library (also 2.2.0) - i was writing about it in my first messages on thread.

I'm successfully pass 3 parts of startup tests with such messages:

*******  Self Test Library Init  *******
 Start-up CPU Test OK
 Start-up FLASH 32-bit CRC OK
 Control Flow Checkpoint 1 OK

After STL_FullRamMarchC success, "restore the data segment initializers from flash to SRAM" section starts and it trying to enable interrupts in code:

/* restore interrupt capability */
    __enable_irq();
//    HAL_SuspendTick();
    /* restore destroyed content of HAL structure for UART */
    huart2.Instance = USARTx;
    huart2.ErrorCode = HAL_UART_ERROR_NONE;
    __HAL_UART_RESET_HANDLE_STATE(&huart2);
    
    /* restore the data segment initializers from flash to SRAM (repeat procedure from IAR & GCC startup) */
    #ifdef __GNUC__
      extern void Startup_Copy_Handler (void);
      Startup_Copy_Handler();
      printf(" Full RAM Test OK\n\r");
    #endif /* GCC Compiler */
    #ifdef __IAR_SYSTEMS_ICC__
      __iar_data_init3();
      printf(" Full RAM Test OK\n\r");
    #endif /* __IAR_SYSTEMS_ICC__ */
  #endif /* STL_VERBOSE_POR */
//  HAL_ResumeTick();
  /* restore interrupt capability */
  __enable_irq();

After __enable_irq() command i stuck in TIM1 time base source timer interrupt forever:I saw in AN4435 that it is possible to have conflicts with "user application" interrupts, but i can't see some recommendation for solution of such a problem.

I was trying to use HAL_SuspendTick before and after enable_irq, but it doesn't help as i understood it anyway enables interrupt and it will be triggered right after enable and stuck in that interrupt forever.

NOTE: Also if i will use step by step passing of the TIM1 interrupt through debugger stepping it will return from it (idk why). And than jump again to TIM1 handler and stuck if i resume debugger in Startup_Copy_Handler().

So can you recommend something to handle such a problem with tick interrupts?

[AMukh.3]

As well as i understood this TIM1 is triggered as freeRTOS tick handler (because i have FreeRTOS middleware added to project). It is inited in HAL_InitTick function during startup tests.

And if i reconfigure HAL_InitTick function to work with SysTick_Handler at start the tests stop to stuck in TIM1 interrupt handler forever. I'm planning to enable this timer after the HAL_Init already in main function, not in startup stage...

Is this workaround is normal in that case ?

[Petr Sladecek]

Note all the modification of the assembly startup file forcing an early call of STL_StartUp during standard C-level initialization is very drastic modification with potential of corrupting this process (manly due to RAM area content destroyed overall by the RAM self-test). Any attempt to recover the destroyed RAM content at main is strongly dependent on compiler behavior during C-level initialization (here at the example is rather focused to restore RAM data necessary to continue at some debugging functionalities like recovering UART verbose mode and LED blinking). I'm not expert of freeRTOS but suppose its RAM data recovery would not be quite trivial. That is why whatever initialization of such a FW performed after RAM full test (done later from main loop at best case) would be better and safe. Be careful, SysTick handler is used for handling partial steps of the STL run time test, too (see stm32f4xx_it.c file). Maybe you should solve this conflict as well when combine STL with the RTOS.

Rgds,

Petr

[AMukh.3]

Thank you for your consultations, @Petr Sladecek​ 

I've managed to setup it all, without damage to my application logic.

One more thing that i wan't to ask, if it is possible to move the systick_handler called STL_TranspMarch() test to the my application part, to not use the interrupt context for a long time?

I'm thinking about doing it with the semaphore in the following way:

As well as i can see this should not break the XCUBE-CLASSB library logic.

[Petr Sladecek]

Of course, it is not necessary to perform calls of run partial ram test steps from here but be careful the interrupts must be masked during its execution (associated RAM content is destroyed during the partial step) and take care about control flow handling, too.

Rgds,

Petr

[NafiurRahman]

Hello,

I am doing a similar implementation. Implementing this Class B Library with FreeRTOS like @AMukh.3. @Petr Sladecek I've read you previous comment about masking the interrupts for the RAM tests. Are there any other tests I have to mask the interrupts?

I have another question. How frequently do I have to call the STL_DoRunTimeChecks(); function? Is there any recommendation by ST?