Cyclic adl_tmr hangs up after a time

Hi everyone,

I would like to inquire, have anybody ever been meet with the following effect?

The cyclic adl_timer hangs up after 30min…8hours time range in target mode.
The used modem: wismo 24pl003, FW: 6.57e, OpenAT 3.17

The timer is 30 sec, in the timer handler I am checking the status of the connection.
I am sure that the program does not exceed the max numbers of simultanously allowed timers.
The code snippet:
#define ReconnectTimein100Ms 300;

Main_timer_30sec = adl_tmrSubscribe ( TRUE, ReconnectTimein100Ms, ADL_TMR_TYPE_100MS, Reconnect_TimerHandler );

void Reconnect_TimerHandler ( u8 ID )
{
…(I am not using any CmdCreate function in the handler)
}”

I am totally bushed…

Thanks for any information or suggestion.

I think your Post is in a wrong place!!!

in any case, the timer declaration looks OK. But what is the functionality inside your timer handler?

also what exactly do you mean by Hang? the timer handler is not called anymore or wat?

I have used timers in my appli, it works great :mrgreen:

Sorry, but I have found some questions concerning the timers only in this section.
Yes, the timer-hanging means, that the timerhandler is not called anymore in spite of the fact, that it is a cyclic timer.

Since then, I have found the problem.
It seems to be that the modem (or the GCC compiler) is not able to handle longer code inside the timerhandler in target mode.
The only way to use a longer code is using a function inside the timerhandler and putting the longer code into this outside-declared function.

I have no information about the reason of this behavior, but it is working.

Best regards,
openat

What do you mean by, “longer code” :question:

I cannot give an exact threshold value, but according to my experience, in case of appr. 100 lines (with string-copy, string-concatenation and wip_write commands) the timer was hanging up after a time, but only in target mode.
When I placed appr. 50 lines into a separate function (which is called from the timerhandler), I have no more experienced this malfunction.