cancel
Showing results for 
Search instead for 
Did you mean: 

ClassB STL_ClockFreqTest with HSI fails frequently on STM8AL3188

RickEleo
Associate

Once the STM8-SafeCLASSB SW package is integrated into our application the Periodic run time self tests are executed continuously but the STL_ClockFreqTest fails randomly. While running the entire application, that test normally fails after about an hour but some other times take 45min or even 4 hours.

We are using the HSI as clock source.

While running a debug session I can see that the measured LSI period is always above the threshold.

We are using IAR for our project.

In our application we also use Timers 3 and 5, SPI1 in slave mode with DMA, SPI2 in master mode, and EXTI.

How to get full stability on this test? Is it possible that some of the mentioned peripherals could affect that test?

Thanks in advance,

Ricardo

1 ACCEPTED SOLUTION

Accepted Solutions
Petr Sladecek
ST Employee

Hello Ricardo,

please focus on function STL_MeasureLSIPeriod(). Great probably, execution flow is corrupted by some additional latency (interrupt service) which causes over capture event signalized by filling the Period variable by zero. Possible cause could be wrong calculation of the Period value, too, when IC1 and IC2 values are captured just when TIM2 counter overflows in between these two captures (despite I would expect most frequent fail at this case). At this case, IC1 value is greater than IC2 and Period variable calculated like IC2 - IC1 can achieve some wrong value. Try to add comparison if IC1> IC2 before this calculation is done and either discard the result (fill Period by zero as well as at case of TIM2 over capture event) or check if the unsigned calculation provide real value even at this timer "over roll" case.

Best regards,

Petr

View solution in original post

2 REPLIES 2
Petr Sladecek
ST Employee

Hello Ricardo,

please focus on function STL_MeasureLSIPeriod(). Great probably, execution flow is corrupted by some additional latency (interrupt service) which causes over capture event signalized by filling the Period variable by zero. Possible cause could be wrong calculation of the Period value, too, when IC1 and IC2 values are captured just when TIM2 counter overflows in between these two captures (despite I would expect most frequent fail at this case). At this case, IC1 value is greater than IC2 and Period variable calculated like IC2 - IC1 can achieve some wrong value. Try to add comparison if IC1> IC2 before this calculation is done and either discard the result (fill Period by zero as well as at case of TIM2 over capture event) or check if the unsigned calculation provide real value even at this timer "over roll" case.

Best regards,

Petr

Indeed, the latency of an interrupt service is messing with the capture event.

Thanks a lot for your reply