MCEWiki - User contributions [en]

Data mode

2009-03-18T18:22:18Z

24.82.145.130: /* Data Modes and Windowing */

= MCE Data Types =
There are 5 types of data that the MCE can return in data packets:
# '''sq1_fb''': the feedback applied by the MCE to the 1st stage SQUIDs:
#* <math>sq1\_fb_{n+1} = \frac{1}{2^{12}} \left[\left(gainp \times error_{n}\right) + \left(gaini \times \sum_{i=1}^{n} error_i\right) + \left(gaind \times [error_{n} - error_{n-1}]\right) \right]</math>
#* Where <math>\sum_{i=1}^n error_i</math> is the integral of the error from the moment the pixel was locked, and
#* Where <math>\left[error_{n} - error_{n-1} \right]</math> is the difference between the current error value and the previous one.
#* Where 'n' is the frame period index
#* Where 'i' is the frame period index since the PID-loop was locked (servo_mode = 3)
# '''error''': the error calculated from the Series-Array signals sampled by the ADCs:
#* <math>error = \sum_{i=1}^{sample\_num} (adc\_reading_{i} - adc\_offset)</math>
# '''sq1_fb_filtered''': the low-pass filtered SQ1 feedback (see [[ Digital 4-pole Butterworth Low-pass filter | 4-pole Butterworth low-pass filter ]]). The effective DC gain, including quantization error, is approximately:
#* <math>sq1\_fb\_filtered_{n} \simeq 1218 \times \left[sq1\_fb_{n-1}\right]</math>
# '''num_flux_jumps''': the value stored in the flux-jump counter. See [[ Flux jumping ]].
#* <math>num\_flux\_jumps_{n} = \frac{1}{flux\_quanta} \left[(sq1\_fb_{n}) - (sq1\_fb\_applied\_to\_DAC_{n})\right] </math>
# '''raw_data''': raw data sampled @ 50 MHz. See [[ Raw-mode readout ]].
#* <math>raw\_data = \left[adc\_reading - adc\_offset\right]</math>

= Data Modes and Windowing =
* Current as of Readout Card firmware revision 4.0.c)
* The data modes below offer the types of data listed above in various combinations, and with different windowings. Each data point in a data packet is 32 bits wide, and may have several types of data packed into it. The table below specifies the different packings.
* The table below makes liberal use of variables '''sq1_fb, error, sq1_fb_filtered, num_flux_jumps,''' and '''raw_data''', which are defined above.
* Generally, a data packet contains one data point per pixel, although there are exceptions to this:
** Fast Data: packets contain data for a subset of pixels to allow readout at a faster rate: [[ High rate acquisition ]].
** Raw Data: packets contain a 50MHz time stream of data starting from row zero.

{| border="1"
|-
! Data Mode !! Summary !! Pixel-Data Description !! RC Firmware Revision
|-
| 0
|| Error
|| 32b (signed) co-added Error signal err[31:0]. 
 
Break-down by bit-field:
* [31:0] '''error_mode0''' = error

|| all
|-
| 1
|| Feedback
||'''When servo_mode = 3:'''
32b (signed) SQ1 Feedback data fb[31:0]. 
 
Break-down by bit-field:
* [31:0] '''feedback_mode1a''' = sq1_fb * 212
 

Because servo_mode=3 is the normal running condition, only feedback_mode1a is supported by most MAS programs. The non-servoing form, feedback_mode1b, is included here for completeness.

'''When servo_mode != 3:'''
32b (signed) SQ1 Feedback from the rc? fb_const registers. These are DAC values. 
 
Break-down by bit-field:
* [31:0] '''feedback_mode1b''' = sq1_fb

|| all
|-
| 2
|| Filtered feedback
||32b (signed) low-pass filtered SQ1 feedback data fb[31:0]. 
 
Break-down by bit-field:
* [31:0] '''filtered_fb_mode2''' = sq1_fb_filtered

|| 2.0.5 and later
|-
| 3
|| Raw 50 MHz
|| Raw 50 MHz ADC samples raw[13:i], where i=0 in rev. 4.3.7 and i=6 in all previous firmware. 
 
Break-down by bit-field:
* [31:0] '''raw_mode3''' = raw_data / (2i),

|| Only 3.0.6, 3.0.16, 3.0.25, 4.1.7, 4.2.7, 4.3.7
|-
| 4
|| 18:14 Mixed
||Signed 18b SQ1 feedback fb[31] & fb[28:12] + signed 14b coadded error signal err[31] & err[12:0]. 
 
Break-down by bit-field:
* [31:14] '''feedback_mode4''' = sq1_fb
* [13:0] '''error_mode4''' = error

|| 2.0.9 and later
|-
| 5
|| 24:8 mixed
|| Signed 24b SQ1 feedback fb[31:8] + signed 8b num_flux_jumps fj[7:0]. 
 
Break-down by bit-field:
* [31:8] '''feedback_mode5''' = sq1_fb * 24
* [7:0] '''num_flux_jumps_mode5''' = num_flux_jumps

|| all
|-
| 6 obsolete
|| 18:14 mixed
|| Signed 18b filtered data filter[31] & filter[27:11] + signed 14b coadded error signal err[31] & err[12:0]. 
 
Break-down by bit-field:
* [31:13] '''filtered_fb_mode6''' = sq1_fb_filtered / (211)
* [12:0] '''error_mode6''' = error

|| 3.0.30 to 4.0.6 only
|-
| 7
|| 22:10 mixed
|| Signed 22b filtered data filter[31] & filter[27:7] + signed 10b coadded error signal err[31] & err[12:4]. 
 
Break-down by bit-field:
* [31:10] '''filtered_fb_mode7''' = sq1_fb_filtered / (27)
* [9:0] '''error_mode7''' = error / (24)

|| 4.0.2 and later
|-
| 8 obsolete
||24:8 mixed
|| Signed 24b filtered data filter[31:8] + signed 8b num_flux_jumps fj[7:0]. 
 
Break-down by bit-field:
* [31:8] '''filtered_fb_mode8''' = sq1_fb_filtered / (28)
* [7:0] '''num_flux_jumps_mode8''' = num_flux_jumps

|| 4.0.4 only
|-
| 9
|| 24:8 mixed
|| Signed 24b filtered data filter[31] & filter[23:1] + signed 8b num_flux_jumps fj[7:0]. 
 
Break-down by bit-field:
* [31:8] '''filtered_fb_mode9''' = sq1_fb_filtered/ (21)
* [7:0] '''num_flux_jumps_mode9''' = num_flux_jumps

|| 4.0.5 and later
|-
| 10
|| 25:7 mixed
|| Signed 25b filtered data filter[27:3] + signed 7b num_flux_jumps fj[6:0]. 
 
Break-down by bit-field:
* [31:7] '''filtered_fb_mode10''' = sq1_fb_filtered / (23)
* [6:0] '''num_flux_jumps_mode10''' = num_flux_jumps

|| 4.1.6, 4.0.b and later
|}

= Automatic loading of data with mas_data.pro =
Please note that, by default, [[ mas_data.pro ]] will rescale data in the following way:
* error signals are rescaled to match the units of data mode 0.
* sq1 feedback is rescaled to sq1_feedback (DAC) units (i.e. data mode 1 divided by 212)
* filtered sq1 feedback is rescaled to the units of data mode 2.

This means the IDL user does not need to worry about the windowing of the different data modes for many applications.

= Links =
* [[ MCE firmware ]]
* [[ Main Page ]]

MCE hardware

2009-02-18T20:09:57Z

24.82.145.130: /* MCEv2 5-MDM Instrument Backplane design notes */

== MCEv2 5-MDM Instrument Backplane design notes ==
Here is the schematic posted for review:
[[http://www.phas.ubc.ca/~mce/projects/spider-spud-bicep2/system/MCEv2_Inst_Backplane/design/elec/C587-201_A_5MDM_IB/C587-201_INST_BP.pdf | IB schematics]]

For the record, here are some of the design decisions, currently not too late to change them:

* '''implementation of configurable jumpers '''
In previous backplane designs, jumpers were implemented either as PCB traces or solder jumpers. The former had the problem of not being configurable as we had to cut traces. The latter had the problem that the assembler wouldn't put the solder jumpers on and since they are not on the BOM, it became hard to track whether they were done or not. Therefore, we settled on the following solution for the new design:
** Jumpers for signal pairs have reference designators of JPn and JNn (eg. JP1 and JN1 are signal pair jumpers)
** These jumpers are called out on the BOM as zero ohm resistors or DNP (do not populate) parts
** Zero ohm resistors will not be used for connect ground planes, copper traces will be used

* ''' MDM routing of low-noise bias lines '''
How to divide up the Low Noise Bias Signals between the new Bias Cards.
** We need to maintain compatibility with existing Bias Cards which should ground these new backplane signal lines.
** Maximizing the number of Low Noise Bias Signals we could get 10 on each of BC1-BC3 for a total of 30.
** How we route them to the MDM connectors is limited but we have a few options, what seems to be best to me is
*** P2 gets LN_BIAS_00 to 08
*** P3 gets LN_BIAS_09 to 15 (P3 also has DET_BIAS_ORG and PXL_HTR)
*** P4 gets LN_BIAS_16 to 23 with 1 spare signal (pair)
*** P5 gets LN_BIAS_24 to 29 with 3 spare signal (pair)

* '''Mechanical and Cosmetic Changes '''
** Include provisions for clamping Hirose connectors
** Reorder Resistor Reference Designators so they are in order on the PCB

* '''Design Concerns '''
** A considerable number of signal lines now have 0805 zero ohm jumpers which may be difficult to layout in the space available

MAS

2009-02-17T19:15:34Z

24.82.145.130: /* Usage */

== Usage ==

* System applications
** [[mce_cmd]]
** [[mce_status]]
** [[maslog]]
** [[dsp_cmd]]
** [[ MAS Command line how-to ]]

* Special applications
** [[ sq1_servo and sq2_servo ]]
** [[ mce_ramp ]]
** [[ psc_status ]]

* Utilities

* MAS configuration
** [[ MAS start/stop ]]
** [[ mce.cfg ]]
** [[ mas.cfg ]]
** [[ MAS array_id and array_list | array_id and array_list ]]

* MAS file formats
** [[ Runfile format v2 ]]
** [[ MCE flat-file format ]]

* Utilities for loading data
** IDL [[ mas_data.pro | data ]] and [[ mas_runfile.pro and mas_runparam.pro | runfile]] scripts
** [[ Python data and runfile modules ]]

* IDL scripts
** [[ auto_setup_squids.pro ]]

* Help
** [[ MCE: Helper programs ]]
** [[ MAS Cheat Sheet ]]
** [[ MCE Recovery During Acquisition ]]

== Development ==

* [[ MAS Bug List ]]
* [[ MAS to-do ]]
* [[ MAS feature requests ]]

== Installation / configuration ==

* [[ MAS PC requirements and initial setup | PC requirements and initial setup]]
* [[ MAS OS setup | OS setup]]
* [[ MAS user setup ]]
* [[ MAS kernel patch compilation | kernel patch compilation]]
* [[ MAS svn repository | SVN repository]]
* [[ Hardware goodlist/badlist ]]

== Trouble-shooting ==

* [[ MAS malfunction diagnosis | diagnosis ]]

Auto-setup (IDL)

2009-02-05T20:38:31Z

24.82.145.130:

This script tunes a squid array using the MCE.

== Overview ==

The steps in the tuning are roughly the following:
# "SA ramp": Ramp the SA feedback to select the SA output value of the lock-point (at this stage it is also possible to ramp the SA bias to find a V-phi curve of maximum amplitide).
# "SQ2 servo": Ramp the SQ2 feedback and servo the SA feedback to determine the SA feedback at lock-point.
# "SQ1 servo": For a single SQ1 in each column , ramp the SQ1 feedback and servo the SQ2 feedback to determine the SQ2 feedback at lock-point.
# "SQ1 ramp": For each SQ1, ramp the SQ1 feedback and determine the SA output value correction (ADC_offset) of the lock-point.

In addition to these, there is a final acquisition of a few hundred frames to evaluate the lock of each detector. This is called "frametest". Following this test, and independent of it, the servo parameters of channels known to be dead or problematic are turned off.

== Tuning parameters ==

Most tuning parameters (such as biases, servo gains, SQ1 servo row selections) are defined in the [[experiment.cfg]] file. Contact UBC for help with this.

== Auto script ==

Command-line access is via auto_setup_squids_sh, called like this:
auto_setup_squids_sh <level> <cards>

Where:
* level is one of 0,1,2 and selects what parts of the tuning to perform
** 0 (default): full tuning of all stages of the array.
** 1: perform only the "SQ1 servo" and the "SQ1 ramp"
** 2: perform only the "SQ1 ramp"
* cards is one of s,1,2,3,4, with s the default:
** Note for "s": this will tune all *4* readout cards. 'rcs' support for systems with 2 readout cards is still in development.

== IDL calling parameters ==

The IDL function declaration is (as of r397)
pro auto_setup_squids, COLUMN=column, ROW=row, RCs=rcs, interactive=interactive, text=text, numrows=numrows, note=note, ramp_sa_bias=ramp_sa_bias, check_bias=check_bias, short=short, quiet=quiet

Parameters that continue to be supported are:
* '''rcs''' (int array): an array of readout card numbers to tune. e.g. [1,2].
* '''note''' (string): a string to pass to the DB registration program (for logging)
* '''short''' (int): causes tuning of only particular stages of the array (useful for correcting minor drifts due to changing thermal or magnetic environments)
* '''ramp_sa_bias''' (switch): forces ramping of the SA bias during the SA ramp step. This can also be controlled through experiment.cfg
* '''check_bias''' (switch): causes the script to check for biasing of the SA and SQ2. If these are off, they are biased on and the script delays execution for a couple of minutes to let the system equilibrate.
* '''quiet''' (int): when set to 1 or 2, reduces text output to the terminal.

Parameters that no one really uses but might still work:
* '''column''' and '''row''' (int array): columns and rows to plot in the final frametest step.

Parameters that are probably broken or definitely meaningless:
* '''interactive'''
* '''text'''

MAS

2009-02-05T20:01:55Z

24.82.145.130: /* Usage */

== Usage ==

* System applications
** [[mce_cmd]]
** [[mce_status]]
** [[maslog]]
** [[dsp_cmd]]
** [[ MAS Command line how-to ]]

* Special applications
** [[ sq1_servo and sq2_servo ]]
** [[ mce_ramp ]]
** [[ psc_status ]]

* Utilities

* MAS configuration
** [[ MAS start/stop ]]
** [[ mce.cfg ]]
** [[ mas.cfg ]]
** [[ MAS array_id and array_list | array_id and array_list ]]

* MAS file formats
** [[ Runfile format v2 ]]
** [[ MCE flat-file format ]]

* IDL functions
** [[ mas_data.pro ]]
** [[ mas_runfile.pro and mas_runparam.pro ]]
** [[ Other useful IDL routines ]]

* IDL scripts
** [[ auto_setup_squids.pro ]]

* Help
** [[ MCE: Helper programs ]]
** [[ MAS Cheat Sheet ]]
** [[ MCE Recovery During Acquisition ]]

== Development ==

* [[ MAS Bug List ]]
* [[ MAS to-do ]]
* [[ MAS feature requests ]]

== Installation / configuration ==

* [[ MAS PC requirements and initial setup | PC requirements and initial setup]]
* [[ MAS OS setup | OS setup]]
* [[ MAS user setup ]]
* [[ MAS kernel patch compilation | kernel patch compilation]]
* [[ MAS svn repository | SVN repository]]
* [[ Hardware goodlist/badlist ]]

== Trouble-shooting ==

* [[ MAS malfunction diagnosis | diagnosis ]]

PCI card firmware

2009-01-14T04:03:36Z

24.82.145.130:

* [[ PCI card bug list ]]
* [[ PCI card to-do]]
* [[ PCI card code assembly on Linux ]]
* [[ PCI card hacking ]]

PCI card hacking

2009-01-14T04:02:37Z

24.82.145.130: /* MCE command, reply and data buffers */

This page describes using dsp_cmd and mce_cmd to debug MCE/PCI card communication issues. These instructions can be used to resolve questions like "is the data getting dropped by the PCI card, or does it never arrive at the PCI card?"

== RAM areas on the DSP ==

The DSP has 3 RAM banks, known as X, Y, and P. User data is in X and Y, while the program code is in P. By default, all three banks contain something like 2k x 16bits. On our hardware, however, the Y bank has been extended with an external SRAM to 8M x 16bits.

In our firmware, X memory is used to store ordinary variables while Y memory is used for large buffers.

== Reading and writing DSP RAM with dsp_cmd ==

We can use dsp_cmd to read back the values of variables and buffers in the PCI card RAM. This is done as follows:
mhasse@mce-ubc-2:~$ dsp_cmd -x read X 0
This is dsp_cmd version MAS/slotpc/327
Line 0 : ok : X[0] = 0x208

We can also write. Don't write to X or P memory unless you really know what you're doing.
mhasse@mce-ubc-2:~$ dsp_cmd -x write Y 0 0x1234
This is dsp_cmd version MAS/slotpc/327
Line 0 : ok

It is convenient to define a few functions to make this hacking easier (you can just dump this into your bash session, or put it in a file and run "source file" whenever you want the functions to be available):
function pciread {
dsp_cmd -qpx read $1 $2 | cut -d' ' -f5
}
function pciwrite {
dsp_cmd -qpx write $1 $2 $3
}
function pcidump {
# usage: pcidump <BANK> <START> <COUNT>
for i in `seq -f '%9.0f' $2 $(( $2 + $3 - 1 ))`; do printf "%s %#8x 0x%06x\n" $1 $i `pciread $1 $i`; done
}
function pciwash {
# usage: pciwash <BANK> <START> <COUNT> <VALUE>
for i in `seq -f '%9.0f' $2 $(( $2 + $3 - 1 ))`; do pciwrite $1 $i $4; done
}

Then you use them like this:
mhasse@mce-ubc-2:~$ pciread x 0
0x208
mhasse@mce-ubc-2:~ pciwrite y 0 0x1234

mhasse@mce-ubc-2:~$ pcidump Y 0x100000 4
Y 0x100000 0x004f4b
Y 0x100001 0x00474f
Y 0x100002 0x000016
Y 0x100003 0x000003

== MCE command, reply and data buffers ==

We can inspect the DSP's buffers if we know their addresses. This depends on DSP code firmware revision.

{| border="1" width=400
! Version !! Data !! Reply !! Command
|-
| U0104 and earlier || 0 || 0 || 0x200
|-
| U0105 || 0 || 0x100000 || 0x200000
|}

'''Notes about data buffers:'''
* because DSP words are 24 bits wide, and MCE words are 32 bits wide, 32-bit data is broken into pairs of 16-bit words, with the lower order bits coming first. So the 32-bit value 0x12345678 is stored as [0x005678, 0x001234].
* in reply and data packets, the preamble, packet type, and frame size are stripped off. These will not appear in the buffers in Y memory. They are available at special locations in X memory, however.

(Incidentally, the collision between the "data" and reply/command buffers in version U0104 and earlier is why U0105 is required to be able to issue STOP or other MCE commands during frame acquisition.)

== DSP internal variables ==

There are a few DSP internal variables, stored in X memory, that are of use in comm. hacking:

{| border="1"
! Name !! Address(U0104) !! Address(U0105) !! Description
|-
| STATUS || 0x00 || 0x00 || Status (and modes) of DSP, see bit break-down below
|-
| MODE || n/a || 0x01 || Flags configuring certain modes of the DSP
|-
| HEAD_W3_0 || 0x21 || 0x14 || Type of last reply or data packet, 'DA' or 'RP'
|-
| PACKET_SIZE_LOW || 0x23 || n/a || Size of latest reply or data packet, in 16 bit words
|-
| PACKET_SIZE || n/a || 0x2B || Size of latest reply or data packet, in 32 bit words
|-
| QT_FRAME_SIZE || 0x53 || 0x3D || The expected size of data packets in bytes
|-
| FRAME_COUNT || 0x01 || 0x02 || Number of DA packets received from the MCE (including discards)
|-
| QT_DROPS || 0x5A || 0x44 || Number of data packets dropped due to full PC RAM buffer
|-
| RP_DROPS || n/a || 0x48 || Number of reply packets dropped due to PC RAM buffer unavailable (quiet_RP mode only)
|}

Currently, the number of packets that are dropped due to a packet size mismatch between PACKET_SIZE and QT_FRAME_SIZE is not recorded explicitly. However, such packets will cause FRAME_COUNT to increment.

All of the above variables, except STATUS, MODE, and FRAME_COUNT are cleared by a DSP_RESET. You can zero the frame count manually using pciwrite.

(Incidentally, the addresses in the table above are determined from the .lod symbol table of the assembler output.)

== Examples ==

Firmware version U0105 is assumed below. Use the functions defined above.

=== Inspect a command packet ===

Note that in current firmware, packets are copied into the DSP buffer *at the same time* as they are transmitted to the MCE. So if your data appears in the DSP buffer, it has also been sent out on the FO transmitter.

We issue
mhasse@mce-ubc-2:~$ mce_cmd -x "wb cc led 7"
and then inspect the packet in the DSP buffer:
mhasse@mce-ubc-2:~$ pcidump y 0x200000 128
y 0x200000 0x00a5a5
y 0x200001 0x00a5a5
y 0x200002 0x005a5a
y 0x200003 0x005a5a
y 0x200004 0x002020
y 0x200005 0x005742
y 0x200006 0x000002
y 0x200007 0x000099
y 0x200008 0x000000
y 0x200009 0x000001
y 0x20000a 0x000000
y 0x20000b 0x000007
y 0x20000c 0x000000
y 0x20000d 0x000000
...
y 0x20007c 0x000000
y 0x20007d 0x000000
y 0x20007e 0x002022
y 0x20007f 0x0057dd

=== Is the MCE returning data? ===

Suppose "mce_run" is blocking without data and we want to check the frame data. We first fill the data buffer with a signature we can recognize:
mhasse@mce-ubc-2:~$ pciwash y 0x0 4096 0x123456

and we may as well zero the frame counter, too.
mhasse@mce-ubc-2:~$ pciwrite x 0x2 0

Then we trigger a go somehow. mce_run is easiest.
mhasse@mce-ubc-2:~$ mce_run test_1935 1 1
RUNFILE_NAME=/data/cryo/current_data//test_1935.run
FRAME_BASENAME=/data/cryo/current_data//test_1935

This hangs, so we Ctrl-C it.

We confirm that the DSP received a single frame from the MCE:
mhasse@mce-ubc-2:~$ pciread x 2
0x1

Now inspect the data buffer:
pcidump y 0x0 4096 > dump.txt
(This can take a while.) Inspecting the output we see reasonable data up to address 0x200:
...
y 0x1fd 0x00ffff
y 0x1fe 0x00f38d
y 0x1ff 0x00ffff
y 0x200 0x123456
y 0x201 0x123456
y 0x202 0x123456
...

Because the FO fifo can hold 1024 16-bit words, what we have here is a complete half-fifo. The PCI card is likely blocking, waiting for the FIFO to be half-full again so it can empty it efficiently. It is at this point that we suspect that the packet size might be the problem.

Our RC1, 41-row frame should have size 372 DWORDS = 1488 bytes. We check that this is what the DSP expects (QT_FRAME_SIZE):
mhasse@mce-ubc-2:~$ pciread x 0x3d
0x5d0
That's 372. Good. Compare with the size of the most recent packet (PACKET_SIZE):
mhasse@mce-ubc-2:~$ pciread x 0x2b
0x54c
Thats 1356 DWORDS = 5424 bytes! That's the size of a full (4-RC, 41 row) frame.

However, the DSP has only buffered 0x200 * 2 = 1024 bytes before stalling. Therefore it appears that the MCE is reporting a 5424 byte packet but then sending somewhere between 1024 and 2047 bytes of data.

PCI card hacking

2009-01-14T03:50:10Z

24.82.145.130:

This page describes using dsp_cmd and mce_cmd to debug MCE/PCI card communication issues. These instructions can be used to resolve questions like "is the data getting dropped by the PCI card, or does it never arrive at the PCI card?"

== RAM areas on the DSP ==

The DSP has 3 RAM banks, known as X, Y, and P. User data is in X and Y, while the program code is in P. By default, all three banks contain something like 2k x 16bits. On our hardware, however, the Y bank has been extended with an external SRAM to 8M x 16bits.

In our firmware, X memory is used to store ordinary variables while Y memory is used for large buffers.

== Reading and writing DSP RAM with dsp_cmd ==

We can use dsp_cmd to read back the values of variables and buffers in the PCI card RAM. This is done as follows:
mhasse@mce-ubc-2:~$ dsp_cmd -x read X 0
This is dsp_cmd version MAS/slotpc/327
Line 0 : ok : X[0] = 0x208

We can also write. Don't write to X or P memory unless you really know what you're doing.
mhasse@mce-ubc-2:~$ dsp_cmd -x write Y 0 0x1234
This is dsp_cmd version MAS/slotpc/327
Line 0 : ok

It is convenient to define a few functions to make this hacking easier (you can just dump this into your bash session, or put it in a file and run "source file" whenever you want the functions to be available):
function pciread {
dsp_cmd -qpx read $1 $2 | cut -d' ' -f5
}
function pciwrite {
dsp_cmd -qpx write $1 $2 $3
}
function pcidump {
# usage: pcidump <BANK> <START> <COUNT>
for i in `seq -f '%9.0f' $2 $(( $2 + $3 - 1 ))`; do printf "%s %#8x 0x%06x\n" $1 $i `pciread $1 $i`; done
}
function pciwash {
# usage: pciwash <BANK> <START> <COUNT> <VALUE>
for i in `seq -f '%9.0f' $2 $(( $2 + $3 - 1 ))`; do pciwrite $1 $i $4; done
}

Then you use them like this:
mhasse@mce-ubc-2:~$ pciread x 0
0x208
mhasse@mce-ubc-2:~ pciwrite y 0 0x1234

mhasse@mce-ubc-2:~$ pcidump Y 0x100000 4
Y 0x100000 0x004f4b
Y 0x100001 0x00474f
Y 0x100002 0x000016
Y 0x100003 0x000003

== MCE command, reply and data buffers ==

We can inspect the DSP's buffers if we know their addresses. This depends on DSP code firmware revision.

{| border="1" width=400
! Version !! Data !! Reply !! Command
|-
| U0104 and earlier || 0 || 0 || 0x200
|-
| U0105 || 0 || 0x100000 || 0x200000
|}

*Note about data and reply packets!*: the preamble, packet type, and frame size are stripped off. These will not appear in the buffers in Y memory. They are available at special locations in X memory, however.

(Incidentally, the collision between the "data" and reply/command buffers is why U0104 and earlier cannot be used to issue STOP or other MCE commands during frame acquisition.)

== DSP internal variables ==

There are a few DSP internal variables, stored in X memory, that are of use in comm. hacking:

{| border="1"
! Name !! Address(U0104) !! Address(U0105) !! Description
|-
| STATUS || 0x00 || 0x00 || Status (and modes) of DSP, see bit break-down below
|-
| MODE || n/a || 0x01 || Flags configuring certain modes of the DSP
|-
| HEAD_W3_0 || 0x21 || 0x14 || Type of last reply or data packet, 'DA' or 'RP'
|-
| PACKET_SIZE_LOW || 0x23 || n/a || Size of latest reply or data packet, in 16 bit words
|-
| PACKET_SIZE || n/a || 0x2B || Size of latest reply or data packet, in 32 bit words
|-
| QT_FRAME_SIZE || 0x53 || 0x3D || The expected size of data packets in bytes
|-
| FRAME_COUNT || 0x01 || 0x02 || Number of DA packets received from the MCE (including discards)
|-
| QT_DROPS || 0x5A || 0x44 || Number of data packets dropped due to full PC RAM buffer
|-
| RP_DROPS || n/a || 0x48 || Number of reply packets dropped due to PC RAM buffer unavailable (quiet_RP mode only)
|}

Currently, the number of packets that are dropped due to a packet size mismatch between PACKET_SIZE and QT_FRAME_SIZE is not recorded explicitly. However, such packets will cause FRAME_COUNT to increment.

All of the above variables, except STATUS, MODE, and FRAME_COUNT are cleared by a DSP_RESET. You can zero the frame count manually using pciwrite.

(Incidentally, the addresses in the table above are determined from the .lod symbol table of the assembler output.)

== Examples ==

Firmware version U0105 is assumed below. Use the functions defined above.

=== Inspect a command packet ===

Note that in current firmware, packets are copied into the DSP buffer *at the same time* as they are transmitted to the MCE. So if your data appears in the DSP buffer, it has also been sent out on the FO transmitter.

We issue
mhasse@mce-ubc-2:~$ mce_cmd -x "wb cc led 7"
and then inspect the packet in the DSP buffer:
mhasse@mce-ubc-2:~$ pcidump y 0x200000 128
y 0x200000 0x00a5a5
y 0x200001 0x00a5a5
y 0x200002 0x005a5a
y 0x200003 0x005a5a
y 0x200004 0x002020
y 0x200005 0x005742
y 0x200006 0x000002
y 0x200007 0x000099
y 0x200008 0x000000
y 0x200009 0x000001
y 0x20000a 0x000000
y 0x20000b 0x000007
y 0x20000c 0x000000
y 0x20000d 0x000000
...
y 0x20007c 0x000000
y 0x20007d 0x000000
y 0x20007e 0x002022
y 0x20007f 0x0057dd

=== Is the MCE returning data? ===

Suppose "mce_run" is blocking without data and we want to check the frame data. We first fill the data buffer with a signature we can recognize:
mhasse@mce-ubc-2:~$ pciwash y 0x0 4096 0x123456

and we may as well zero the frame counter, too.
mhasse@mce-ubc-2:~$ pciwrite x 0x2 0

Then we trigger a go somehow. mce_run is easiest.
mhasse@mce-ubc-2:~$ mce_run test_1935 1 1
RUNFILE_NAME=/data/cryo/current_data//test_1935.run
FRAME_BASENAME=/data/cryo/current_data//test_1935

This hangs, so we Ctrl-C it.

We confirm that the DSP received a single frame from the MCE:
mhasse@mce-ubc-2:~$ pciread x 2
0x1

Now inspect the data buffer:
pcidump y 0x0 4096 > dump.txt
(This can take a while.) Inspecting the output we see reasonable data up to address 0x200:
...
y 0x1fd 0x00ffff
y 0x1fe 0x00f38d
y 0x1ff 0x00ffff
y 0x200 0x123456
y 0x201 0x123456
y 0x202 0x123456
...

Because the FO fifo can hold 1024 16-bit words, what we have here is a complete half-fifo. The PCI card is likely blocking, waiting for the FIFO to be half-full again so it can empty it efficiently. It is at this point that we suspect that the packet size might be the problem.

Our RC1, 41-row frame should have size 372 DWORDS = 1488 bytes. We check that this is what the DSP expects (QT_FRAME_SIZE):
mhasse@mce-ubc-2:~$ pciread x 0x3d
0x5d0
That's 372. Good. Compare with the size of the most recent packet (PACKET_SIZE):
mhasse@mce-ubc-2:~$ pciread x 0x2b
0x54c
Thats 1356 DWORDS = 5424 bytes! That's the size of a full (4-RC, 41 row) frame.

However, the DSP has only buffered 0x200 * 2 = 1024 bytes before stalling. Therefore it appears that the MCE is reporting a 5424 byte packet but then sending somewhere between 1024 and 2047 bytes of data.

PCI card hacking

2009-01-14T03:23:23Z

24.82.145.130: