Basically when stopCalPulse2AllChannelsLocal(...) tries to write 0x0 to the CAL_ENABLE register of channel 94 of VFAT15 on OH10 of eagle61 the writeReg call appears to hang indefinitely.
However when calling this on OH11 there's no issue at all.
Additionally when trying to write this channel's register with gem_reg.py there's no issue.
Finally when writing with setChannelRegistersVFAT3Local:
There's no issue with channel 94 of this VFAT. But interestingly this function doesn't use the bit mask to write CAL_ENABLE and just builds the channel register with bitwise operations.
I'm out of ideas as to what the cause is...the only thing I can think of is there's an issue with LMDB for specifically this address+bit mask combination (although what I do not know).
Tomorrow I will try to move this OH to eagle26 and see if the problem still occurs on that CTP7.
Types of issue
[x] Bug report (report an issue with the code)
[ ] Feature request (request for change which adds functionality)
Expected Behavior
It shouldn't hang forever on a specific channel for a specific link...
Current Behavior
....it hangs forever on the specific channel for this specific link.
Steps to Reproduce (for bugs)
from gempython.tools.vfat_user_functions_xhal import HwVFAT
vfatBoard = HwVFAT("eagle61",10)
# vfatBoard.stopCalPulses(0x8805,0,127) # works
vfatBoard.stopCalPulses(0x805,0,127) # hangs indefinitely
Possible Solution (for bugs)
🤷♂️
Context (for feature requests)
Causes a weird bug which makes trimming not possible.
Your Environment
Version used: 78bfc744a7ba1cdb9c3d320bcbf5585c38553ffc
Brief summary of issue
I came across an interesting issue with:
https://github.com/cms-gem-daq-project/ctp7_modules/blob/78bfc744a7ba1cdb9c3d320bcbf5585c38553ffc/src/optohybrid.cpp#L548
For full details see: http://cmsonline.cern.ch/cms-elog/1079167
Basically when
stopCalPulse2AllChannelsLocal(...)tries to write0x0to theCAL_ENABLEregister of channel 94 of VFAT15 on OH10 of eagle61 thewriteRegcall appears to hang indefinitely.However when calling this on OH11 there's no issue at all.
Additionally when trying to write this channel's register with
gem_reg.pythere's no issue.Finally when writing with
setChannelRegistersVFAT3Local:https://github.com/cms-gem-daq-project/ctp7_modules/blob/78bfc744a7ba1cdb9c3d320bcbf5585c38553ffc/src/vfat3.cpp#L380
There's no issue with channel 94 of this VFAT. But interestingly this function doesn't use the bit mask to write
CAL_ENABLEand just builds the channel register with bitwise operations.I'm out of ideas as to what the cause is...the only thing I can think of is there's an issue with
LMDBfor specifically this address+bit mask combination (although what I do not know).Tomorrow I will try to move this OH to
eagle26and see if the problem still occurs on that CTP7.Types of issue
Expected Behavior
It shouldn't hang forever on a specific channel for a specific link...
Current Behavior
....it hangs forever on the specific channel for this specific link.
Steps to Reproduce (for bugs)
Possible Solution (for bugs)
🤷♂️
Context (for feature requests)
Causes a weird bug which makes trimming not possible.
Your Environment
/bin/zsh