Tracking down the source of FEX_ERROR
In the case when DCZ produces damages, the BaBar FastMon reports it.
However, it does not tell which rom is responsible for it within the
DCZ system. One can take a look at the XTC file and track down the source
of it.
By running a program below:
cd ~eunil/links/u01/teststand
srtpath
xtciter -f /nfs/bstore/g/ir2logs/runs-0048500/babar-0048910-001.xtc -n 10000
[...]
Extent 0x0b824 ts 0x319578/12e1e79b src 0x13 svc 0x15 dmg 0x00004000
Crate 30 has damage 0x4000
found ROM 1f size 0 dmg 0
found ROM 1 size 1b0 dmg 0
found ROM 1f size 0 dmg 0
found ROM 2 size 61c dmg 4000
Extent 0x08cf0 ts 0x319578/135ba2ff src 0x05 svc 0x15 dmg 0x00004000
Crate 30 has damage 0x4000
found ROM 1f size 0 dmg 0
found ROM 1 size c8 dmg 0
found ROM 1f size 0 dmg 0
found ROM 2 size 5e0 dmg 4000
Extent 0x0906c ts 0x319578/1391edfb src 0x17 svc 0x15 dmg 0x00004000
Crate 30 has damage 0x4000
found ROM 1f size 0 dmg 0
found ROM 1 size 108 dmg 0
found ROM 1f size 0 dmg 0
found ROM 2 size 5e0 dmg 4000
The above output tells us that the source of the damage 0x4000 is from
the zpd rom.
It shows that the TSF rom (ROM 1) returns no damage but the zpd rom (ROM 2)
returns 0x4000 all the time from the run 48910 data. Since the size
is > 0, it must be the glink error (There are two sources of the fex
error in the zpd fex code: one is the glink error and the other is the
buffer that contains the daq data being empty).
Eunil Won
Last
modified: Fri 12 Mar 2004 
