|NOTE: Old contents of BU CMS wiki. These (green) pages cannot be edited|
See www.hcal.info for more links to active TWikis
The "htr spy" program (htr.cc) is a convenient way to initialize and control an oSLB using scripts (or by hand). To get started:
./htr -s 11 (start program, specify VME slot 11) HTR> slb (go to SLB menu) SLB> slb 3 (select SLB site 3 -- always 3 for oSLB) SLB> r 0xb (read register 0xb, corresponding to oSLB address 0x2c)
The current firmware version will be read by the last command. Note that the values used for the read and write commands in the htr oSLB menu are currently always hex. Also, the address used is the register number times 4, so to access (i.e. offset 0x2c from the documentation, use 0x2c/4 = 0xb.)
oslb specv9: execute the script reset_oslb.htr (in which w 4 0x80 sets the GOLs to send data).
Scripts, in order of execution:
Then configure and enable the TTCci you're using, and issue a test_enable.
Back on lxcmdtest3, lower crate (bus 120).
HTR fw 00046.mcs on all HTR FPGAs (use ./htr -u -7 to configure all HTRs in a crate with a given fw version). Successful test. oslb was v9.
Now to compile a working version of Wu's oslb programs cfgFPGA and writeFLASH on our teststand. I hate dependent libraries. ''2007-09-28''
Modified scripts by deleting the TTCvi menu commands; the teststand is using TTCci in another crate, anyway, and ./htr is unable to cope.
Using these scripts, with htr firmware 0x0183F in both FPGAs of both HTRs, and oSLBv9, walking muon pulses became walking muon bits, first in GOL0 and GOL2, with GOL1 sending correctly-formatted zeros. Editting the reset_oslb.htr script to begin by writing 1 to addr 0x0 (instead of writing 0), which put the test patterns into GOL1 but zeros into GOL0 and GOL2, as expected.
''Problem'' When trying the above tests again with htr fw 45 (current newest), and with 40, only zeros were observed in any of the three channels. The same fw was in all four htrs for each version test. A return to fw 3f was attempted, but we never recovered the spikes. Instead, zeroes were returned (and occasionally empty-buffer data, the 0x3ffff like the receiving HTR sees on the channels we aren't using).
And then the power to the racks we were using tripped. Help has been contacted, and we're moving to other projects in the meantime.
Relocated the sending and receiving HTRs to the crate run by cmsmoe4, to continue work while the power issue on the rack by lxcmdtest3 awaits its slow, bureaucratic resolution.
This crate has a TTCvi, not a TTCci. The pulses from the oslb are now seen as walking bits on all three of the appropriate channels of the receiving HTR again. Same behavior after a crate power cycle and a re-running of the htr script. HTRs all runing fw 0x183F. Why was it two-or-one before, but all three now?
Changed transmitting HTR FPGAs to fw 0x1840, which should be nominally the same. Repeat of test and crate cycle equally successful.
Changed receiving HTR FPGAs to fw 0x1840, too.