VMEStream Echo Test about cms-calo-layer1

[ekfriis]

@nwoods @tsarangi you should be able to test this at Chamberlin once
Mathias gives you a VME enabled BE bitfile

On Wed, Oct 30, 2013 at 11:09 AM, Austin Belknap
[email protected]:

The VMEStream executable vme2fd needs to be tested with the hardware. A
description of the usage of vm2fd is in the Wiki:
https://github.com/uwcms/cms-calo-layer1/wiki/The-oRSC#vmestream.

The vmestream_echo_test runs on the oRSC back-end:
https://github.com/dabelknap/cms-calo-layer1/tree/master/orsc_be_vmestream_echo_test.
It takes data from VME (sent from vme2fd) and resends it back to vme2fd.
From the VMEPC, a sample session should look like this:

$ ./vme2fd orsc_send orsc_recv

In a separate terminal,

$ echo "put that in your pipe and smoke it" > orsc_send

The string should be read by vme2fd, sent to the oRSC via VME, then sent
back to vme2fd. The string should then appear in the output named pipe.

$ cat osrc_recv
put that in your pipe and smoke it

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/42
.

[dabelknap]

I have started working on the echo test w/ the latest VME RAM definitions. Single read/write and block read/write operations work fine. However, as vme2fd loops, the value of the size registers somehow become corrupted. Haven't determined the cause yet.

[dabelknap]

@mathiasblake
@pklabbers
Do you know if repeated (identical) VME read/write operations can cause corruption to the data stored in the RAM or the registers? In vme2fd, the values of the registers and the RAM seem to be fine for a few loops. Somehow, one of the registers gets set to 0xffff during a CAEN read/write operation (I'm not sure which). This causes a segmentation fault since the value of this register is used to determine how much data to read from a buffer. What is also strange is that the number of loops before this error appears is different each time I run vme2fd.

[pklabbers]

I haven't seen such a problem on the RCT's registers or accessing the LUTs (memory chips for the RCT). Could the
VME be accessing something else in the crate? The RCT cards VME LEDs blink if they are accessed, the 0xFFFF looks like what one gets if one trys to read out a LUT without settting a card in read mode first.

[pklabbers]

I had a thought - is the RCT crate booted? Could it be that you are accessing unprogrammed RCT cards. I cannot vouch for their good behavior if their VME addresses haven't been set up properly in a "caenRCTBoot".

[dabelknap]

Yes, I tried booting the crate and problem persists. Also, the addresses I am accessing are on the oRSC.

[dabelknap]

I think the problem is more nefarious than I originally thought. I wrote a skeleton version of vme2fd and slowly added in components bit-by-bit. Everything works fine until I initialize a VMEStream struct: then, the corrupted register problem appears. It might not be a VME problem, but rather a compiler/UNIX issue.

[dabelknap]

I just created an example that reproduces the problem. If you would like to have a look, it is located here: https://gist.github.com/dabelknap/7467516. It turns out that VMEStream wasn't the cause after all.

[dabelknap]

I have also tried power-cycling the crate, and this didn't help either.