Experimental Physics and
Industrial Control System

[email protected] (Jeff Hill) · Mon, 14 Sep 1998 15:26:43 -0600

On Monday, September 14, 1998 2:15 PM, Dayle Kotturi [SMTP:[email protected]] wrote:
> Hello tech-talk,
> 
> My system is running on an mv167 talking to an Allen Bradley PLC
> via a KE1785 module. I am getting the following error:
> 
> Access Fault
> Program Counter: 0x00ed99dc
> Status Register: 0x3004
> Access Address : 0xae907496
> Special Status : 0x0525
> 
>  27b18 _vxTaskEntry   +10 : _shell (0, 0, 0, 0, 0, 0, 0, 0, 0, 0)
>  56154 _shell         +138: 56172 ([0, 0, 0, 55f78, 0])
>  562f4 _shell         +2d8: _execute (f7799e)
>  56418 _execute       +ac : _yyparse ([0, 0, 0, f7799e, 0])
>  5a682 _yyparse       +514: 5904c (e594e8, e59508)
>  59158 _yystart       +758: _iocInit (f6f4a4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0)
> e7792e _iocInit       +286: e77fb4 ([&_yyval, 5, &_iocInit, 580d4, 0])
> e78068 _iocInit       +9c0: _devInitAbDf1 (1)
> e527d8 _devInitAbDf1  +22 : _drvAbDf1InitiateAll ([f77830, e7806a, 1, 64, &_iocInit])
> ed5904 _drvAbDf1InitiateAll+38 : _drvAbDf1InitiateLink (db0eb0)
> ed5af4 _drvAbDf1InitiateLink+8c : ed8d02 (db10e8, 0)
> ed8d7e _drvAbDf1WriteBinary+45e: ed9266 (d8b4c4)
> ed92b4 _drvAbDf1WriteBinary+994: ed987c (d8b4c4, f777a0)
> 
> I have been seeing (and ignoring) this error for months now. It happens
> quite regularly (every 3rd or 4th reboot of the crate). To date, I 
> haven't used any debugging tools on this, but have just put in a bunch
> of printfs in the code. The last printf to print before the crash is
> consistently in the routine "drvAbDf1InitCache" called from within the 
> "if (type == absWrite)" clause of drvAbDf1InstallWordIO. And, even 
> though the last subroutine to be mentioned in the crash is "drvAbDf1WriteBinary",
> no printfs from that routine are printed. 

The above stack trace indicates that "_drvAbDf1WriteBinary+994" is
the final location of the code. This does not always indicate that the
processor is in function drvAbDf1WriteBinary(). The processor might also
be in routines within the GNU compiled source code after drvAbDf1WriteBinary() 
that are "static" and therefore module scope (not exported to the global symbol
table used by tt()). It appears that the code really is in drvAbDf1InitCache()
in this situation since it is static in scope and drvAbDf1WriteBinary() is the
next global scope function above it in the GNU compiled source code. To find
out for certain add the line "#define LOCAL" to the source code immediately
after including the vxWorks header files, recompile the code and reboot the 
IOC.

As I recall this problem occurs because of a race condition between a task
that has been spawned by iocInit during initialization and iocInit itself. A
data structure is used before it is fully initialized. With the above information 
it is difficult to be certain, but I strongly suspect that this problem has been 
seen before and already fixed in the latest version. The race condition 
perhaps more likely to occur in systems configured with slower serial link 
speeds.

With KECK's permission I will place the latest version on anonymous FTP.
Note that this version has been in stable production use here with PLC5s for about
6 months with only very minor changes. The latest version has not been tested with 
earlier PLCs, but should work with them with very few if any modifications. Note that 
if you are using drvSerial with other drivers then I will need to finish merging Alan's 
changes to drvSerial into mine so that the code will be backwards compatible. I
made a change to drvSerial so that there is no need to delete tasks when a serial
connection drops out. This eliminates the possibility of deleting a task that owns
a mutex semaphore that does not have the "task delete safe" option set.
Also note that the new AB DF1 driver has been updated so that output records 
are processed whenever the DF1 target value is changed in the PLC. This
change was made to meet operational requirements at our site.
Existing database designs should be carefully examined whenever
a DF1 output record forward links to another record.

Jeff

______________________________________________________
Jeffrey O. Hill                      Internet     [email protected]
LANL MS H820                    Voice         505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System