AN370
Rev. 1.0
27
6.5. Infinite Loops
Some of the API functions rely on the functioning hardware for functionality. They wait for some hardware action to
finish. If the hardware is not configured correctly and the hardware block never gives the "finished" status to the
API function, the system gets stuck in an infinite loop.
It is the user application responsibility to either make sure the hardware is configured correctly so the infinite lockup
does not occur or to provide a timer driven interrupt with possible timeout global error flag to be checked after the
return from the "stuck" function. The timer ISR, when invoked after timeout, would have to touch the hardware to
notify the "stuck" function that the hardware is done while setting a global error flag at the same time that the
operation of the stuck function was invalid.
Table 5 show the functions which potentially could wait forever for a feedback from hardware and possible ways to
correct it in the timer ISR watchdog scenario.
Table 5. Potential Infinite Loop Functions
Function
Wait for action
HW required
ISR remedy
vFc_PollDone
FC_DONE
FC f_count & f_int present
FC_DONE=1
lFc_StartPollGetCount
FC_DONE
FC f_count & f_int present
FC_DONE=1
vStl_PreLoop
Temp samples > 0
DMD TS & ISR
Note 1
vSys_LpOscAdj
Temp samples > 0
DMD TS & ISR
Note 1
iMVdd_Measure
Temp samples > 0
(3 times)
DMD TS & ISR
Note 1
vStl_PostLoop
ODS_NODATA &
ODS_EMPTY
ODS functioning
vOds_Enable(0)
2
vFCast_Tune
FC_DONE (5 times)
FC f_count & f_int present
FC_DONE=1
Temp samples > 0
DMD TS & ISR
Note 3
XO_CKGOOD (if
XO_ENA=1)
XO functioning
(if XO_ENA=1)
No remedy
4
Notes:
1.
The DMD TS must be running and the DMD TS ISR must be present in the system and functional and processing
samples, otherwise the whole system is not functional. There is no value in providing a timer driven watchdog for DMD
TS block and related functions above.
2.
If the ODS hardware is functioning correctly and is configured using API it will never get stuck and the vStl_PostLoop()
function will not stall.
3.
The frequency counter must have both main counter signal f_count and interval counter signal f_int running to
produce any result. If either of those signal is not running then the frequency counter gets stuck indefinitely and never
produces FC_DONE=1.
4.
It can only happen if XO_ENA=1 before vFCast_Tune() is called. The function will wait indefinitely for the XO to
produce stable output, XO_CKGOOD=1. There is no remedy if the XO does not work and keeps XO_CKGOOD=0.
The function will wait forever. If the user needs reliable hardware it is up to them main application to check that the
XO_CKGOOD=1 (while XO_ENA=1) before calling vFCast_Tune(). Possible remedy in timer ISR would be to check
the XO_CKGOOD bit and if not set then skip the interrupt address and return directly to the main application. The
status of the hardware would be undetermined in that situation.