kewakl (Customer) asked a question.
I am trying to do some unorthodox programming.
It works in STOP->Debug.Step mode but not in RUN mode in either hardware or simulator.
I realize that some aspects of the PAC family/applications cannot be simulated, but I feel that this should not be an issue.
I am attempting to find the upper bound of an array at runtime. I do know the upper bound at design time.
I clear the Noncritical error log, attempt to loop through an array using a FOR loop with a "number of loops' that should exceed the array size.
I attempt to trap the Number of Noncritical Errors in the list.
The code works in step mode, but not in run mode.
In Simulator run mode, failure ONE is that I must trigger the routine twice.
In Simulator run mode, failure TWO is that the Number of Noncritical Errors does not interrupt the FOR loop.
In hardware run mode, the failure is that the Number of Noncritical Errors does not interrupt the FOR loop.
In hardware AND simulator, the loop is interrupted as I expect -- when the loop count exceeds the array upper bound.
Note: there is some other (disabled) code in here that I intended to use because I would NOT want to use 'Number of Noncritical Errors' for this purpose - another noncrit error happening DURING this process cause erroneous array ubound checking.
In STOP->Debug mode, I add a breakpoint at rung 9 (CPD x -> ArraySize), set 'trig' then run to breakpoint -- watching the ArraySize tag attempt to exceed the actual array column count of 19.
I may add to this post as I obtain more insights.
The error count is only updated outside of the scan, like I/O is. The count updating within the FOR loop during debug mode is a known behavior, and cannot be changed due to firmware/watchdog requirements.
To avoid a hardware watchdog trigger, the firmware execution isn’t actually halting between steps in debug mode, so it has the time to recalculate the error count, where in run mode, the error count isn’t actually updated until the housekeeping phase of the scan.