Skip to main content
R
RickEleo
Visitor II
September 12, 2022
Solved

ClassB STL_ClockFreqTest with HSI fails frequently on STM8AL3188

  • September 12, 2022
  • 1 reply
  • 1458 views

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

    This topic has been closed for replies.
    Best answer by Petr Sladecek

    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

    1 reply

    P
    Petr SladecekAnswer
    ST Employee
    September 26, 2022

    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

    R
    RickEleoAuthor
    Visitor II
    September 29, 2022

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

    Thanks a lot for your reply

    Terms & ConditionsAccessibility statement