cancel
Showing results for 
Search instead for 
Did you mean: 

functions (e.g. printf) not working in timer callback function (Systick, Timer)

Jaeho
Associate

Hello,

I usually make a code based on the timer callback function to handle multiple tasks.

However, I don't know why functions like printf in the systick callback function don't work at all if the flag switching is in the same function.

It works If I put the same code in the main loop, but not in the callback function.

 

These kinds of problems sometimes happen with other functions, not only with printf.

I kindly wonder which point makes these results from the controller.

 

For example (flag is a global variable with 0 initial value),

 

void HAL_SYSTICK_Callback(void)

{

if(flag == 0){

printf("Check\r\n");

}

}

==> This gives tons of UART messages through printf func.

 

void HAL_SYSTICK_Callback(void)

{

if(flag == 0){

flag = 1;

printf("Check\r\n");

}

}

 

==> This never give any UART messages.

 

If it is done in the main function,

 

int main(void)

{

... init functions ...

while(1)

{

if(flag == 0){

flag = 1;

printf("Check\r\n");

}

}

==> This correctly gives UART message only once.

 

 

 

1 ACCEPTED SOLUTION

Accepted Solutions
Danish1
Lead II

Callback functions happen while the processor is "servicing an interrupt".

An interrupt can happen at any moment. The processor might be busy doing a printf or any number of other things. And unless very carefully written (which costs memory and processor-time, as well as your effort in configuring it), you can't do two things like printf at the same time.

And while the processor is servicing one interrupt, any interrupt at the same or lower-priority cannot happen.

For these reasons, many people follow a rule never to put any time-consuming actions inside an interrupt or interrupt-callback. This includes sending information to other peripherals (e.g. via printf) because peripherals are much slower than the processor.

I guess this is one of those things that "comes with experience" that ST don't bother to state in one of their documents describing a particular processor or peripheral. But it should be in most books on how to do embedded programming.

View solution in original post

2 REPLIES 2
AScha.3
Chief III

Hi,

if in INT /callback you use a (global) variable, it has to be "volatile" ; so compiler knows, not to use register for this.

Try...

+

Dont forget about INT priority: in callback using something, that needs an INT , but that one is on lower priority, never will get the lower prio INT.

If you feel a post has answered your question, please click "Accept as Solution".
Danish1
Lead II

Callback functions happen while the processor is "servicing an interrupt".

An interrupt can happen at any moment. The processor might be busy doing a printf or any number of other things. And unless very carefully written (which costs memory and processor-time, as well as your effort in configuring it), you can't do two things like printf at the same time.

And while the processor is servicing one interrupt, any interrupt at the same or lower-priority cannot happen.

For these reasons, many people follow a rule never to put any time-consuming actions inside an interrupt or interrupt-callback. This includes sending information to other peripherals (e.g. via printf) because peripherals are much slower than the processor.

I guess this is one of those things that "comes with experience" that ST don't bother to state in one of their documents describing a particular processor or peripheral. But it should be in most books on how to do embedded programming.