We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi
I am using the RTL RTX from Keil
Version 3.01 in an LC2214
Has anyone had any problems with "os_dly_wait" running longer than the time interval set.
We are running a base load task which basically operates as follows:
{
forever
os_dly_wait for 350ms Call function to kick a hardware pin on the micro. This clears the pin, calls another os_dly_wait for 10ms, sets the pin then exits back to base load
os_dly_wait for 350ms call a function to check 5 software tasks have completed (which are always ok as we have monitored these) exit back to base load
Call function to kick a hardware pin on the micro. This clears the pin, calls another os_dly_wait for 10ms, sets the pin then exits back to base load
loop }
The harware pin being kicked is connected to a watchdog input of a supervisor IC
What is happening is that after approximately 4 days the hardware pin stops toggling, causing the supervisor IC to reset the micro.
If the hardware pin is removed from the supervisor IC and monitored on a scope it stops toggling for a time greater than 35 seconds and then restarts. Also the system and all of its outputs operate perfectly.
All of the tasks being checked in the software check are working correctly.
The hardware pin being kicked every 10ms has been remapped to a different pin on a different port and it still hangs.
The os_dly_wait command has been replaced with os_itv_wait in the base load task. Also the os_dly_wait in the function that kicks the hardware pin has been removed and we just clear the pin 3 times in a row then set it. With this change applied the baseload task never stops and the hardware pin always toggles
Has anyone got any idea why this should make a difference or has anyone had similar problems with os_dly_wait
The base load task is the only task that uses os_dly_wait. Every other task uses os_itv_wait. The basload task is the only one that falls over, even though the rest of the system runs perfectly.
Is there a problem with changing the os_dly_wait time out value from 350ms in the base load task, to 10ms in the kickhardwarewatchdog function that kicks the hardware pin, back to 350ms when it goes back into the baseload task.
HELP im going mad !!!
Scott
I'm not at all familiar with RTX so this may be way off base...however,
Is there any correlation among the clock rate of the timer, the word size of the associated counter and the four day period ?
i.e. Could this be a "rollover" issue ?
David