Why TIMER takes time to start up?

[FCamp.1]

Hi,

I have a F439ZI where i have set a simple timer (TIM10) to raise the the HAL_TIM_PeriodElapsedCallback every 1 millisecond.

The Bus APB2 for timers runs at 168 MHz so i set in the configuration 168 in the prescaler (result is 1Mhz) and the i set 1000 in the counter period.

In fact he callback is fired every millisecond as expected. Problem is that it takes around 6 seconds to fire for the first time.

Any idea why?

Thanks a in advance,

Filo

[waclawek.jan · Accepted solution]

> it takes around 6 seconds to fire for the first time.

How do you know?

Is there any other software there, blocking the interrupts - or delays setting up the timer - for about 6 seconds?

JW

[berendi]

Do you measure the 6 seconds from starting the timer, or from powering up/resetting the MCU?

I've played a bit with HAL recently and found that a certain initialization function takes exactly 3 seconds before it silently fails.

[waclawek.jan]

Silently? Not even returning some error code?

There are peripherals which legitimately take seconds to start up, e.g. a well designed LSE oscillator.

JW

[FCamp.1]

Hello,

yes i mean 6 second from the powerup of the device.

Anyway I have fixed, waclawek.jan was right.

There was a ETH service set by CUBEMX by default that was taking time to initialize. The initialization was set in the code before then the TIM start instruction.

Once disabled this service everything went fine.

Thanks a lot to both,

Filo

[berendi]

Yes, CubeMX initialization code silently ignores errors, the only indication is that it takes an an integer multiple of a second longer than it should.

RTC initialization gets confused when the RTC is already running. I was under the impression that the point of having a RTC is to keep it running, but apparently my view is not shared by the CubeMX developers.

HAL functions actually return HAL_ERROR. Very helpful.

MX_RTC_Init() is declared void, but it at least calls Error_Handler() three times. Which has no parameters, so again very helpful. What am I supposed to do, count how many times Error_Handler() was called to determine the nature of the error?

This stuff should be banned. It is harmful. Not just considered harmful, but matter-of-fact harmful.

[Mikhail Z]

Error_Handler() has a user code section where you can add, e.g., while(1).

[berendi]

Not a great idea for a production system.

I'm quite afraid that code like this some day ends up in a system my life depends on.

[waclawek.jan]

berendi is surely aware of that. He complained about the fact that the failed function does not pass any diagnostic i.e. the reason why it failed, to ErrorHandler, which then can't take appropriate measures (e.g. display or log an error message, or recover where possible ), just die in a generic way, as you've suggested.

berendi,

You should take it as it is: a mostly marketing element, aimed at beginners an the naiver part of developer community, partly under the pressure of outside ("everybody does that", is in vogue, ARM also puts this pressure through mbed). That ST *replaced* real examples by Cube is unfortunate.

This should be taught in schools as a cautionary example, the proverbial glitter.

JW

[Mikhail Z]

It is user code, so just add whatever elaborate code you want.

while(1) at least makes it not completely silent.