Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Version 3.8.3] Sbit monitor always reports wrong clusters #38

Open
lpetre-ulb opened this issue Jun 3, 2019 · 1 comment
Open

[Version 3.8.3] Sbit monitor always reports wrong clusters #38

lpetre-ulb opened this issue Jun 3, 2019 · 1 comment

Comments

@lpetre-ulb
Copy link

After upgrading the firmwares to the latest versions (CTP7 - 3.8.3 ; OH - 3.2.3C), the Sbit monitor started to report wrong clusters even if the trigger links are properly initialized. More precisely, the least significant byte is always set to 0xff.

On the other hand, the Sbit monitor implemented within the OH reports the expected cluster (see CLUSTER0) :

eagle63 > kw GEM_AMC.TRIGGER.SBIT_MONITOR
0x66000204 rw   GEM_AMC.TRIGGER.SBIT_MONITOR.OH_SELECT                  0x00000000
0x66000208 r    GEM_AMC.TRIGGER.SBIT_MONITOR.CLUSTER0                   0x000060ff
0x6600020c r    GEM_AMC.TRIGGER.SBIT_MONITOR.CLUSTER1                   0x000007ff
0x66000210 r    GEM_AMC.TRIGGER.SBIT_MONITOR.CLUSTER2                   0x000007ff
0x66000214 r    GEM_AMC.TRIGGER.SBIT_MONITOR.CLUSTER3                   0x000007ff
0x66000218 r    GEM_AMC.TRIGGER.SBIT_MONITOR.CLUSTER4                   0x000007ff
0x6600021c r    GEM_AMC.TRIGGER.SBIT_MONITOR.CLUSTER5                   0x000007ff
0x66000220 r    GEM_AMC.TRIGGER.SBIT_MONITOR.CLUSTER6                   0x000007ff
0x66000224 r    GEM_AMC.TRIGGER.SBIT_MONITOR.CLUSTER7                   0x000007ff
0x66000228 r    GEM_AMC.TRIGGER.SBIT_MONITOR.L1A_DELAY                  0x07b36daa
eagle63 > kw GEM_AMC.OH.OH0.FPGA.TRIG.SBIT_MONITOR
0x65008240 None         GEM_AMC.OH.OH0.FPGA.TRIG.SBIT_MONITOR
0x65008240 w    GEM_AMC.OH.OH0.FPGA.TRIG.SBIT_MONITOR.RESET
0x65008244 r    GEM_AMC.OH.OH0.FPGA.TRIG.SBIT_MONITOR.CLUSTER0          0x00006000
0x65008248 r    GEM_AMC.OH.OH0.FPGA.TRIG.SBIT_MONITOR.CLUSTER1          0x000007ff
0x6500824c r    GEM_AMC.OH.OH0.FPGA.TRIG.SBIT_MONITOR.CLUSTER2          0x000007ff
0x65008250 r    GEM_AMC.OH.OH0.FPGA.TRIG.SBIT_MONITOR.CLUSTER3          0x000007ff
0x65008254 r    GEM_AMC.OH.OH0.FPGA.TRIG.SBIT_MONITOR.CLUSTER4          0x000007ff
0x65008258 r    GEM_AMC.OH.OH0.FPGA.TRIG.SBIT_MONITOR.CLUSTER5          0x000007ff
0x6500825c r    GEM_AMC.OH.OH0.FPGA.TRIG.SBIT_MONITOR.CLUSTER6          0x000007ff
0x65008260 r    GEM_AMC.OH.OH0.FPGA.TRIG.SBIT_MONITOR.CLUSTER7          0x000007ff
0x65008280 r    GEM_AMC.OH.OH0.FPGA.TRIG.SBIT_MONITOR.L1A_DELAY         0x975f6ddf

I'm not sure if the issue is in the OH or the CTP7. My current workaround uses the OH Sbit monitor instead of the CTP7 one.

@evka85
Copy link
Owner

evka85 commented Jun 13, 2019

Hmm interesting... Could you try this with the new CTP7 fw and old OH fw combination? In this combination, the OH FPGA slow control won't work, but the communication to VFATs and also the trigger links should work as expected..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants