SuperKEKB XRM system, Page 1 of 2  Not logged in ELOG logo
 Find |  Login |  Help 
 Full | Summary | Threaded | Show attachments  Show only new entries   31 Entries 
Goto page 1, 2   Next  All
ID Date Author Type Subject
  1   Tue Apr 19 19:09:25 2016 James BynesInstructionsObtaining data from XRM development boardstack
Here are the instructions to obtain data from XRM boardstack. This has currently been tested with 1 carrier board, but little modifications will allow multiple boards. Currently the data
taken is raw data, a pedestal extractor is currently under works.
The current firmware and software branch can be accessible from the svn repo at: https://www.phys.hawaii.edu/repos/belle2/itop/electronics/branches/XRM
**note** The firmware and software bundle can also be temporarily downloaded from Google Drive: https://drive.google.com/file/d/0B7Z8jduXUZ-LbFdUTFdEMkctUnc/view?usp=sharing
**note** Software bundle does not include XRM parser, please download from this ELOG.
**note** The following instructions are written using the directory for the test setup at IDLAB. Please modify the upcoming directories to match your system.

If any questions, please email James (bynes@hawaii.edu) or Luca (lucam@hawaii.edu)

Preliminary Step (setting up the network):
The firmware has been setup to communicate with a workstation using point-to-point topologies.
First, connect a SFP module from the SCROD to a media converter, then connect the Ethernet cable to your workstation.
Workstation IP
Next, we setup the test workstation (at IDLAB) using a static IP address, this machine ran Scientific Linux (red hat variant)
From red hat linux this can be done like so...
Menu System >> Administration >> Network
Statically set IP address:
Address 192.168.10.200
Subnet mask 255.255.255.0
SCROD firmware IP
The firmware is currently set to use IP address 192.168.10.***
where the last 3 digits is the ID of the SCROD. This IP will come in handy when launching the communication GUI.

Step 1 (program FPGA):
First need to source Xilinx settings, if your .bashrc doesn’t already do so.
Directory: /opt/Xilinx/Vivado/2014.4/
Change to c shell, type ‘csh’ in terminal
Source settings64.csh
Directory: /home/idlab/svn-02-18-2016/gigE
Upload bitfiles to FPGAs on chain ‘xmd -tcl program-bit-and-elf-and-go.xmd.tcl’

Step 2 (run GUI):
Directory: /home/idlab/svn-02-18-2016/gigE/software/gigE/
Source setup_env_template.csh
Now run GUI: ‘bin/develTest 192.168.10.101’
**Note** 101 is the SCROD board ID, this should be on the SCROD itself on a whitish label.
To test whether or not link to SCROD is up, from configuration tab on GUI, click “Read Configuration” button on the bottom

Step 3 (configuration):
Next, the configuration script will need to be ran
Directory: /home/idlab/svn-02-18-2016/gigE/software/gigE/pnnl
Run configuration script: './configure_boardstack.csh'
...
In the GUI, will also need to manually configure some settings.
From the Configuration tab, change the following fields to the parameters:
trigMask -> 0xe
featureExtractionMode -> Passthrough
After these two parameters are changed, hit the “Write Configuration” button on the bottom.

Step 4 (pull data):
This current script will take data from carrier 0 (includes all 4 ASICs).
Directory: /home/idlab/svn-02-18-2016/gigE/software/gigE/pnnl/
Run current test script: ‘./runtest.csh’
The binary file will be outputted to data/test_c0_1.bin

Step 5 (parse data):
XRMdataExtractor.c will convert binary data pulled from previous step and output to a readable format. It is attached to this elog
Use: ./XRMdataExtractor <binary_file>
Output files: XRM_header_from_binary_file.txt, XRM_data_from_binary_file.txt
The header file shows format of data file which is as follows:
carrier# | ASIC# | Sample# | CH0 | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | CH7

Upcoming additions:
XRMpedExtractor
XRMdataVisualizer
  2   Sun May 1 01:45:45 2016 James BynesInstructionsSetting up Ubuntu 14.04 to take data from XRM boardstack
This ELOG shows how to obtain data from XRM boardstack from a fresh install of Ubuntu 14.04

i) Freshly install Ubuntu 14.04
Once installation is finished, update all packages:
'sudo apt-get update'
'sudo apt-get upgrade'
'sudo apt-get update'

ii) Add a softlink so that gmake points to make:
'sudo ln -s /usr/bin/make /usr/bin/gmake'

iii) Install the following via 'sudo apt-get install <package>'
libxml2-dev
g++
libbz2-dev
libqt4-dev
python-dev
lib32z1-dev
vim
subversion
tsch

iv) Download software package and make:
Directory: /home/
'svn co https://www.phys.hawaii.edu/repos/belle2/itop/electronics/branches/XRM'
Directory: ~/XRM/software/gigE/
'source setup_env_template.sh'
'make clean'
'make' (should make with no errors)

v) Install Vivado 2014.4 using web pack (used Design edition since limited in space)
'chmod +x Xilinx_installation_file.bin'
'sudo ./Xilinx_installation_file.bin'
install to /opt/Xilinx/...
allow write permissions to Xilinx folder:
'sudo chmod 777 -R /opt/Xilinx/'
'sudo chmod 777 -R ~/.Xilinx'
Open ~/.bashrc in your favorite text editor and add the following:
____________________________________________________
XILINXD_LICENSE_FILE=<your_license>
LM_LICENSE_FILE=<your_license>
export XILINXD_LICENSE_FILE
export LM_LICENSE_FILE
source /opt/Xilinx/Vivado/2014.4/settings64.sh
____________________________________________________
Now show be able to run vivado by typing vivado from xterm

vi) Setting up network for communication with boardstack:
The firmware has been setup to communicate with a workstation using point-to-point topologies.
First, connect a SFP module from the SCROD to a media converter, then connect the Ethernet cable to your workstation.
Workstation IP
From Network Connections, add a new Ethernet connection
From the Ethernet tab, select your network adapter Device MAC Address
Statically set IP address:
On IPv4 tab, select Manual from drop-down list
Click on Add and add the following:
Address: 192.168.10.200
Subnet mask: 255.255.255.0
Gateway: 0.0.0.0
SCROD firmware IP
The firmware is currently set to use IP address 192.168.10.***
where the last 3 digits is the ID of the SCROD. This IP will come in handy when launching the communication GUI.

vii) Program FPGA
Directory: ~/XRM/
Upload bitfiles to FPGAs on chain ‘xmd -tcl program-bit-and-elf-and-go.xmd.tcl’

viii) Run GUI
Directory: ~/XRM/software/gigE/
'Source setup_env_template.sh'
Now run GUI: ‘bin/develTest 192.168.10.101’
**Note** 101 is the SCROD board ID, this should be on the SCROD itself on a whitish label.
To test whether or not link to SCROD is up, from configuration tab on GUI, click “Read Configuration” button on the bottom

ix) Configure boardstack
Open a new terminal window and source setup_env_template.sh again
Directory: ~/XRM/software/gigE/pnnl/
Open configure_boardstack.csh with your favorite text editor
On the line 'foreach carrier(...)', starting from 0, sequential add numbers for the amount of carriers on the boardstack
Example: 'foreach carrier(0 1 2)' is used for 3 carriers on the boardstack
Save and run the file: './configure_boardstack.csh'
On the GUI from the configuration tab, change the following parameters:
trigMask -> 0xe (for 1 carrier), 0xc (for 2 carriers), 0x8 (for 3 carriers)
featureExtractionMode -> Passthrough

x) Pull Data
Directory: ~/XRM/software/gigE/pnnl/
'/.runtest.csh'

xi) Parse Data
Directory: ~/XRM/software/gigE/pnnl/data
Download file attached to this ELOG to directory
Compile: 'gcc -o XRMdataExtractor XRMdataExtractor.c'
Parse data: 'XRMdataExtractor test_c0_1.bin'
Open XRM_data_test_c0_1.bin.txt using your favorite text editor to look at the data

xii) Future Additions
XRMpedExtractor - This program will determine pedestals
  3   Tue May 3 08:11:06 2016 M. Andrewdocumentationwhat was done in January 2016

Here is a data dump of everything that happened on the asus laptop while getting the laste 2015 / early 2016 incarnation of the XRM tested before being delivered to KEK on the weekend of January 24th.  Everything was done in bash and the firmware only addressed one carrier at a time, so the purpose of this elog entry is simply to archive the information.

  4   Sat May 7 20:52:24 2016 James Bynes IIIInstructionsPlotting data from XRM boardstack

The following package will allow you to parse binary data from TargetX and output pedestal subtracted plots as well as a separate pedestal subtract text file in tabbed column format.

You will need python, numpy, scipy, and matplotlib packages installed. If you don't have them already, they can be installed through terminal with the following line (in Debian or Ubuntu):
sudo apt-get install python-numpy python-scipy python-matplotlib


Extract package to $PWD/pnnl/data/ directory

After taking data from XRM boardstack run the following command:
*note* binfile must be in the same directory
python XRM_script.py <binfile> <# of carriers> <# of windows> <plot 1 or 0 (yes or no?)>

The script will automatically compile c code and take pedestals if needed

example: (2 carriers) (4 windows) (yes plot)
python XRM_script.py test_2.bin 2 4 1
test_2.bin in included in download package for testing

Outputs:
Folder plots/ -- All plots will be stored here
XRMdataExtractor -- Data extractor program
XRMpedExtractor -- Pedestal extractor program
XRM_dataheader_<filename>.txt -- Raw data header
XRM_data_<filename>.txt -- Raw data in tab column format
XRM_pedHeader_<filename>.txt -- Pedestal only data header
XRM_ped_<filename>.txt -- Pedestal only data in tab column format
XRM_<filename>_ped_subtracted.txt -- Pedestal subtracted data in tab column format
  5   Tue May 17 16:03:12 2016 Gary Varnerreportcompilation log

Following up on James` suggestion, have posted transcript of compilation log below.

Not sure if there is anything should worry about here.

Strangely, the ton of warnings saw the first time I tried went away...

 

  6   Wed May 18 01:13:55 2016 Chris Ketter, Gary Varneranalysisfirst data sets

After getting data logging earlier in the day, Chris installed the detector and we took a look at data.

The amp board gain is set to lowest setting.  Still, when looking at pedestal subtracted data, the preamps were picking up clear noise.

This may have impacted the pedestals, which were still noisy with preamps off, but long cables/detector connected.

Therefore cables disconnected, and noise demonstrated to be expected (Attachment 1).  In this and subsequent plots, the x-axis sample number (approx 0.36ns/sample) and y-axis is ADC (roughly 1mV/count).

As a training exercise, Chris configured and logged these data sets.

Detector was reconnected and powered, with reference plots for ch0, ch1 in subsequent 2 attachments.

The noise is clearly correlated between channel pairs, as they are interleaved/looking at same signal.

Looking at a different channel (ch6), the noise isn't so clearly correlated.

Because each trace is 4k samples, it is easy to focus on outliers, so a less biased approach is to look at the ensemble distributions.

An example of the two conditions for ch. 1 is posted as the last 2 plots, where the RMS spread is seen to increase from about 2 to 7 ADC counts RMS.

Interesting to compare values in the tunnel.

 

  7   Wed May 18 21:32:21 2016 Gary Varnernoise during RF conditioning(?)carrier 0, asic 0

There is bursts of noise seen in the longer record lengths (1).

Some channels are quieter (2), though all see hints of 500MHz (3).

Channels 6&7 have pick-up that looks very much like 500MHz. (4).

Anyway, there is potentially good news here:

1) we aren`t completely deafened

2) a concurrent EMI baseline subtraction may be possible (use nominally unilluminated channel)

Key will be to see how large signal is.

 

  8   Thu May 19 02:08:09 2016 Gary Varneranalysisstatistics during RF on run

Summary statistics for short [1 run @ 64 windows] (1) and longer [100x] (2) show rather similar responses, where channels 6&7 are clearly noisier, while all others are in decent agreement.

It becomes clearer in the larger statistics that the distribution looks bimodal.  This could be due to amplifier chain instability/oscillation.

As a check of trying a common mode subtraction, did ch1-ch0 (3) and ch2-ch0 (4).  In the first case this perhaps makes sense, if the signal is 500MHz, the phase difference leads to the difference seen.  Should try to plot this modulo period and see if forms a periodogram.  For channels that should be in phase, the improvement isn't as much as would think, so this needs further investigation.

  9   Thu May 19 13:49:23 2016 Gary Varnerdata taking problem reportmorning 20-MAY-2016 JST

After beam came back on overnight, wanted to get a background reference data set.

However when trying to log data via GUI, the trigger number wasn't incrementing, nor a non-zero .bin file being created.

Restarted the GUI and confirmed that registers could be read, but still no response to triggers. 

Tried selecting anoher ASIC and reconfig.  Bricked the GUI.  (Single Event Upset?)

Don't think bit file only FW reflash will work, but can try if unable to get power cycle of APC to work relatively soon.

Otherwise we are dead in the water.

  10   Thu May 19 19:48:14 2016 John Flanagan, Gary Varnernetwork documentationAPC network configuration
host name  : psxrd08
IP address : 172.19.62.89
MAC address: 00:c0:b7:b8:94:f9


> SuperKEKB ネットワーク 登録申請を受け付けました。
> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
>  申請日         : 2016-05-19 15:49:00
>  申請内容       : 新規
>  登録者名       : フラナガン
>  登録者の所属   : Beam Monitor
>  電子メール     : john.flanagan@kek.jp
>  機器の種類     : ネットワーク電源
>  使用OS         : 
>  設置場所       : D4,D8,トンネル内
>  Host name      : psxrd08
>  DHCP server    : Yes
>  MAC address    : 00-c0-b7-b8-94-f9
>  VLAN           : KEKB_CA_1
>  機器の使用用途 : ｘ線モニター用
>  その他         : 
> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
>

  11   Thu May 19 23:01:35 2016 Gary Varneranalysisfirst try

Started a 1Hz run and let it run, the tail end of which might have had the detector in the xray beam.

Stopped run, but the GUI crashed when trying to close the very large (>1.5k event) run.

Large files bit unwieldy to work with, but first time series plot for channel 0 attached (1).

And even more clearly, on log plot, can see nothing going on, so either had already crashed or was never in beam (2).

APC not making DHCP requests, so kinda stuck.

  12   Fri May 20 16:08:46 2016 John Flanagan, Gary Varnerhardware documentationAPC and PDU AC-power settings

Controlling remotely via separate laptop, with connections on the 2 subnets .0  and  .1

APC is currently Default IP  192.168.1.201

apc/apc

LER PDU MAC:
00-06-18-75-4f-57
HER PDU MAC:
00-06-18-75-4f-10

Default IP:
192.168.0.216

user:  snmp
pass:  1234
 

  13   Fri May 20 23:30:23 2016 Chris KetterinformationConfiguration of XRM

Attachment 1 is a block diagram of the XRM setup for the Low Energy Ring (LER). Physically, this is located underneath the right wing of Fuji Hall, tens of meters away from the crossing point of the beams (180deg around ring from interaction point). Directly upstairs is the optics hut where the readout PC is located. 

Attachment 2 details the physical location of all the components around the fermionics detector.

Attachment 3 is picture of the fermionics detector area from farther back.

Attachment 4 shows (somewhat) the source of the X-Rays and the positron beam pipe from which they originate. 

 

  14   Sat May 21 01:02:13 2016 John Flanagan, Gary Varnerrun reportFirst Light!

After a battle to sort out the networking issues with the APC (on loan) and PDU, able to get all working fine, and logged in separate Elog.

The ability to power cycle XRM proved essential as periodically something is happening in the tunnel which causes the network connections (both for XRM and APC) to get cycled.

While the APC can simply be logged into again, XRM requires a reprogram/reconfig cycle.  Interestingly, the link comes back and registers can be read back.

But data taking/writes either are ignored or cause the link to become bricked.  It could be an ARM stop, where some type of soft reset might work.

Anyway, without proper alignment fiducials, were scanning blind.  To try and see something, the mask was removed. hitting the detector with ribbon of x-rays.

Clearly seen in the first attachment.

A zoom in for the 4 pixels being read is shown in the second attachment. 

Obviously some signal processing is going to be needed to deal with the AC-coupled nature of this signal, and possibly induced ringing. 

However the Signal-to-Noise is encouraging, as the amp board is running at minimal gain.

  15   Tue Jan 22 07:56:56 2019 M. Andrewdocumentationinstructions for setup, compiling and data acquisition

File XRM.instructions.txt gives the 2019-era details on running the XRM.

  16   Tue Jun 18 11:29:30 2019 M. Andrewdocumentationraspberry pi

to install:

cd
mkdir -p build
cd ~/build
git clone https://github.com/mzandrew/XRM.git

to run:

cd ~/build/XRM/predator
./get_temperatures.py # reads temps from SPI thermocouple
27.9 26.3
./read_serial.py # reads temp + ADC values from microcontroller for ammeter function
24.8 1.368 1.406
./take_pic.sh 
./lights_on.sh 
./lights_off.sh 
./temperatures.sh # grabs snapshot of KEKB status and plots temperatures on it
./make_video.sh # makes video from individual images
./upload_to_samd21.sh # programs microcontroller (ADC for amplifier's ammeter)
./daemon.sh # started in /etc/rc.local upon bootup - runs in a loop once a minute: get_temperatures.py, read_serial.py and take_pic.sh

notes:

logfile for temperatures and voltages (for ammeter) is in logs/temperatures.log

latest picture is stored in pictures/picture.jpg; then archived with a date/time stamp in the filename (pictures/2019-06-13.105227.jpg)
 

  17   Mon Sep 30 09:36:16 2019 M. Andrewdocumentationmeasurements of accelerator clock and revolution marker

Following Nuclear Instruments and Methods in Physics Research A 499 (2003) 138–166, we know that the distributed accelerator clock is 508.8875 MHz (508.91 MHz measured) and that there are 5120 RF buckets.  So the revolution marker should come at 99.3921 kHz (99.39 kHz measured).

Furthermore, it should be noted that the revolution marker is a 50% duty cycle NIM signal and the accelerator clock is about 600 mVpp.  The RMS of the delay between an edge of the accelerator clock and the revolution marker is about 67 ps.  These measurements were done in the D8 XRM optics hut (Oho) after the addition of cabling and RF/NIM fanout modules were inserted (but before the long cables down to the tunnel).

The scope used for the measurements was a Rhode & Schwartz RTO 1044.

  18   Mon Sep 30 10:59:35 2019 M. AndrewdocumentationAlthea/RAFFERTY

The firmware running on Althea/RAFFERTY https://github.com/mzandrew/hdl/blob/master/verilog/src/mza-test032.pll_509divider_and_revo_encoder_plus_calibration_serdes.althea.v takes a 508.8875 MHz clock input, and uses a PLL to generate 4 phases of a 127.221875 MHz clock (input/4).  Then it uses a 4-bit iserdes on the input clock to register the phase of the revolution marker on the output clock.  It takes about 1 second worth of these and populates a histogram.  Then it uses the most popular choice and outputs the corresponding phase of the 127 MHz so that the boardstack gets a revolution marker on that 127 MHz clock and the "bunch-0" happens during the first quarter of whichever 127 MHz clock the boardstack sees.  This scheme *should* avoid having bunch-0 show up in a different quarter of the 127 MHz clock upon every power cycle.

The measured difference between revolution marker in from accelerator to revolution marker out to boardstack is 93.64 ns.  This is measured on Althea/RAFFERTY in the D8 HER optics hut, but should be similar when in the tunnel because Althea/RAFFERTY has since been moved down there and the cable lengths after that are on the order of ~1 m.  Overall delay from the accelerator revolution marker (in optics hut) to what Althea/RAFFERTY gets is still yet to be measured (and moreover what the phase of that is to when the synchrotron radiation from "bunch-0" goes through the HER He box).

  19   Fri Oct 4 08:55:23 2019 M. Andrewdocumentationinstructions for pdu control
Control of the power distribution unit (pdu) is done from xrd04rp2.  The script pdu.sh is in the $PATH.

to get pdu status:
xrm@xrd04rp2:~$ pdu.sh 
  [on] He box pwr
 [off] Boardstack
0 W total

to power the boardstack on:
xrm@xrd04rp2:~$ pdu.sh on
  [on] He box pwr
  [on] Boardstack
50.0 W total

to turn the boardstack off:
xrm@xrd04rp2:~$ pdu.sh off
  [on] He box pwr
 [off] Boardstack
0 W total
  20   Fri Oct 4 10:04:12 2019 M. Andrewdocumentationinstructions for programming boardstack
Programming the boardstack is done from xrd04rp2.  The script boardstack.sh is in the $PATH.

To make sure the svn repo is up to date, run svnup.sh (also in $PATH) before programming:
xrm@xrd04rp2:~$ svnup.sh 
Updating '.':
At revision 2869.

Program the boardstack:
xrm@xrd04rp2:~$ boardstack.sh 
Open On-Chip Debugger 0.10.0+dev-00930-g09eb941c (2019-09-17-03:49)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Info : clock speed 6000 kHz
Info : JTAG tap: carrier3.pl tap/device found: 0x1372c093 (mfg: 0x049 (Xilinx), part: 0x372c, ver: 0x1)
Info : JTAG tap: carrier3.cpu tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4)
Info : JTAG tap: carrier2.pl tap/device found: 0x1372c093 (mfg: 0x049 (Xilinx), part: 0x372c, ver: 0x1)
Info : JTAG tap: carrier2.cpu tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4)
Info : JTAG tap: carrier1.pl tap/device found: 0x1372c093 (mfg: 0x049 (Xilinx), part: 0x372c, ver: 0x1)
Info : JTAG tap: carrier1.cpu tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4)
Info : JTAG tap: carrier0.pl tap/device found: 0x1372c093 (mfg: 0x049 (Xilinx), part: 0x372c, ver: 0x1)
Info : JTAG tap: carrier0.cpu tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4)
Info : JTAG tap: SCROD.pl tap/device found: 0x23731093 (mfg: 0x049 (Xilinx), part: 0x3731, ver: 0x2)
Info : JTAG tap: SCROD.cpu tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4)
Info : carrier3.cpu.0: hardware has 6 breakpoints, 4 watchpoints
Info : carrier3.cpu.1: hardware has 6 breakpoints, 4 watchpoints
Info : carrier2.cpu.0: hardware has 6 breakpoints, 4 watchpoints
Info : carrier2.cpu.1: hardware has 6 breakpoints, 4 watchpoints
Info : carrier1.cpu.0: hardware has 6 breakpoints, 4 watchpoints
Info : carrier1.cpu.1: hardware has 6 breakpoints, 4 watchpoints
Info : carrier0.cpu.0: hardware has 6 breakpoints, 4 watchpoints
Info : carrier0.cpu.1: hardware has 6 breakpoints, 4 watchpoints
Info : SCROD.cpu.0: hardware has 6 breakpoints, 4 watchpoints
Info : SCROD.cpu.1: hardware has 6 breakpoints, 4 watchpoints
Info : Listening on port 3333 for gdb connections
Info : Listening on port 3334 for gdb connections
Info : Listening on port 3335 for gdb connections
Info : Listening on port 3336 for gdb connections
Info : Listening on port 3337 for gdb connections

-rw-r----- 1 xrm idlab 8695644 Oct  4  2019 SCROD.bitfiles/ScrodRevB_b2tt_00010095.bit
-rw-r----- 1 xrm idlab 3828341 Oct  1 07:35 carrier.bitfiles/CarrierRevE_00000062.bit
-rwxr-x--- 1 xrm idlab 239907 Sep 20 12:54 carrier.elffiles/CarrierRevE_PS_app_00000021.elf
-rwxr-x--- 1 xrm idlab 360637 Sep 17 05:56 SCROD.elffiles/Scrod_PS_app_0000006e.elf
-rw-r----- 1 xrm idlab 20597 Sep 17 05:58 carrier.bitfiles/ps7_init.tcl
-rw-r----- 1 xrm idlab 36137 Sep 17 05:57 SCROD.bitfiles/ps7_init.tcl

-rw-r----- 1 xrm idlab 8695644 Oct  4  2019 SCROD.bitfiles/ScrodRevB_b2tt_00010095.bit
-rw-r----- 1 xrm idlab 3828341 Oct  1 07:35 carrier.bitfiles/CarrierRevE_00000062.bit
programming bit file on SCROD...
programming bit file on carrier 0...
programming bit file on carrier 1...
programming bit file on carrier 2...
programming bit file on carrier 3...

-rwxr-x--- 1 xrm idlab 239907 Sep 20 12:54 carrier.elffiles/CarrierRevE_PS_app_00000021.elf
-rwxr-x--- 1 xrm idlab 360637 Sep 17 05:56 SCROD.elffiles/Scrod_PS_app_0000006e.elf
-rw-r----- 1 xrm idlab 20597 Sep 17 05:58 carrier.bitfiles/ps7_init.tcl
-rw-r----- 1 xrm idlab 36137 Sep 17 05:57 SCROD.bitfiles/ps7_init.tcl

halting all the ARMs...
Error: Can't assert SRST: nSRST signal is not defined
Info : JTAG tap: carrier3.pl tap/device found: 0x1372c093 (mfg: 0x049 (Xilinx), part: 0x372c, ver: 0x1)
Info : JTAG tap: carrier3.cpu tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4)
Info : JTAG tap: carrier2.pl tap/device found: 0x1372c093 (mfg: 0x049 (Xilinx), part: 0x372c, ver: 0x1)
Info : JTAG tap: carrier2.cpu tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4)
Info : JTAG tap: carrier1.pl tap/device found: 0x1372c093 (mfg: 0x049 (Xilinx), part: 0x372c, ver: 0x1)
Info : JTAG tap: carrier1.cpu tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4)
Info : JTAG tap: carrier0.pl tap/device found: 0x1372c093 (mfg: 0x049 (Xilinx), part: 0x372c, ver: 0x1)
Info : JTAG tap: carrier0.cpu tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4)
Info : JTAG tap: SCROD.pl tap/device found: 0x23731093 (mfg: 0x049 (Xilinx), part: 0x3731, ver: 0x2)
Info : JTAG tap: SCROD.cpu tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4)
Warn : carrier3.cpu.0: ran after reset and before halt ...
Warn : carrier3.cpu.1: ran after reset and before halt ...
Warn : carrier2.cpu.0: ran after reset and before halt ...
Warn : carrier2.cpu.1: ran after reset and before halt ...
Warn : carrier1.cpu.0: ran after reset and before halt ...
Warn : carrier1.cpu.1: ran after reset and before halt ...
Warn : carrier0.cpu.0: ran after reset and before halt ...
Warn : carrier0.cpu.1: ran after reset and before halt ...
Warn : SCROD.cpu.0: ran after reset and before halt ...
Warn : SCROD.cpu.1: ran after reset and before halt ...
Info : carrier3.cpu.0 rev 0, partnum c09, arch f, variant 3, implementor 41
Info : carrier3.cpu.0: MPIDR level2 0, cluster 0, core 0, multi core, no SMT
Info : carrier3.cpu.1 rev 0, partnum c09, arch f, variant 3, implementor 41
Info : carrier3.cpu.1: MPIDR level2 0, cluster 0, core 1, multi core, no SMT
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x000001d3 pc: 0xffffff34
MMU: disabled, D-Cache: disabled, I-Cache: disabled
target halted in ARM state due to debug-request, current mode: System
cpsr: 0x200001df pc: 0xffffff28
MMU: disabled, D-Cache: disabled, I-Cache: disabled
Info : carrier2.cpu.0 rev 0, partnum c09, arch f, variant 3, implementor 41
Info : carrier2.cpu.0: MPIDR level2 0, cluster 0, core 0, multi core, no SMT
Info : carrier2.cpu.1 rev 0, partnum c09, arch f, variant 3, implementor 41
Info : carrier2.cpu.1: MPIDR level2 0, cluster 0, core 1, multi core, no SMT
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x000001d3 pc: 0xffffff34
MMU: disabled, D-Cache: disabled, I-Cache: disabled
target halted in ARM state due to debug-request, current mode: System
cpsr: 0x200001df pc: 0xffffff28
MMU: disabled, D-Cache: disabled, I-Cache: disabled
Info : carrier1.cpu.0 rev 0, partnum c09, arch f, variant 3, implementor 41
Info : carrier1.cpu.0: MPIDR level2 0, cluster 0, core 0, multi core, no SMT
Info : carrier1.cpu.1 rev 0, partnum c09, arch f, variant 3, implementor 41
Info : carrier1.cpu.1: MPIDR level2 0, cluster 0, core 1, multi core, no SMT
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x000001d3 pc: 0xffffff34
MMU: disabled, D-Cache: disabled, I-Cache: disabled
target halted in ARM state due to debug-request, current mode: System
cpsr: 0x200001df pc: 0xffffff28
MMU: disabled, D-Cache: disabled, I-Cache: disabled
Info : carrier0.cpu.0 rev 0, partnum c09, arch f, variant 3, implementor 41
Info : carrier0.cpu.0: MPIDR level2 0, cluster 0, core 0, multi core, no SMT
Info : carrier0.cpu.1 rev 0, partnum c09, arch f, variant 3, implementor 41
Info : carrier0.cpu.1: MPIDR level2 0, cluster 0, core 1, multi core, no SMT
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x000001d3 pc: 0xffffff34
MMU: disabled, D-Cache: disabled, I-Cache: disabled
target halted in ARM state due to debug-request, current mode: System
cpsr: 0x200001df pc: 0xffffff28
MMU: disabled, D-Cache: disabled, I-Cache: disabled
Info : SCROD.cpu.0 rev 0, partnum c09, arch f, variant 3, implementor 41
Info : SCROD.cpu.0: MPIDR level2 0, cluster 0, core 0, multi core, no SMT
Info : SCROD.cpu.1 rev 0, partnum c09, arch f, variant 3, implementor 41
Info : SCROD.cpu.1: MPIDR level2 0, cluster 0, core 1, multi core, no SMT
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x000001d3 pc: 0xffffff34
MMU: disabled, D-Cache: disabled, I-Cache: disabled
target halted in ARM state due to debug-request, current mode: System
cpsr: 0x200001df pc: 0xffffff28
MMU: disabled, D-Cache: disabled, I-Cache: disabled
Error: Can't assert SRST: nSRST signal is not defined
Info : JTAG tap: carrier3.pl tap/device found: 0x1372c093 (mfg: 0x049 (Xilinx), part: 0x372c, ver: 0x1)
Info : JTAG tap: carrier3.cpu tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4)
Info : JTAG tap: carrier2.pl tap/device found: 0x1372c093 (mfg: 0x049 (Xilinx), part: 0x372c, ver: 0x1)
Info : JTAG tap: carrier2.cpu tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4)
Info : JTAG tap: carrier1.pl tap/device found: 0x1372c093 (mfg: 0x049 (Xilinx), part: 0x372c, ver: 0x1)
Info : JTAG tap: carrier1.cpu tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4)
Info : JTAG tap: carrier0.pl tap/device found: 0x1372c093 (mfg: 0x049 (Xilinx), part: 0x372c, ver: 0x1)
Info : JTAG tap: carrier0.cpu tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4)
Info : JTAG tap: SCROD.pl tap/device found: 0x23731093 (mfg: 0x049 (Xilinx), part: 0x3731, ver: 0x2)
Info : JTAG tap: SCROD.cpu tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4)
Info : carrier3.cpu.0 rev 0, partnum c09, arch f, variant 3, implementor 41
Info : carrier3.cpu.1 rev 0, partnum c09, arch f, variant 3, implementor 41
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x00000193 pc: 0xffffff34
MMU: disabled, D-Cache: disabled, I-Cache: disabled
target halted in ARM state due to debug-request, current mode: System
cpsr: 0x2000019f pc: 0xffffff28
MMU: disabled, D-Cache: disabled, I-Cache: disabled
Info : carrier2.cpu.0 rev 0, partnum c09, arch f, variant 3, implementor 41
Info : carrier2.cpu.1 rev 0, partnum c09, arch f, variant 3, implementor 41
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x00000193 pc: 0xffffff34
MMU: disabled, D-Cache: disabled, I-Cache: disabled
target halted in ARM state due to debug-request, current mode: System
cpsr: 0x2000019f pc: 0xffffff28
MMU: disabled, D-Cache: disabled, I-Cache: disabled
Info : carrier1.cpu.0 rev 0, partnum c09, arch f, variant 3, implementor 41
Info : carrier1.cpu.1 rev 0, partnum c09, arch f, variant 3, implementor 41
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x00000193 pc: 0xffffff34
MMU: disabled, D-Cache: disabled, I-Cache: disabled
target halted in ARM state due to debug-request, current mode: System
cpsr: 0x2000019f pc: 0xffffff28
MMU: disabled, D-Cache: disabled, I-Cache: disabled
Info : carrier0.cpu.0 rev 0, partnum c09, arch f, variant 3, implementor 41
Info : carrier0.cpu.1 rev 0, partnum c09, arch f, variant 3, implementor 41
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x00000193 pc: 0xffffff34
MMU: disabled, D-Cache: disabled, I-Cache: disabled
target halted in ARM state due to debug-request, current mode: System
cpsr: 0x2000019f pc: 0xffffff28
MMU: disabled, D-Cache: disabled, I-Cache: disabled
Info : SCROD.cpu.0 rev 0, partnum c09, arch f, variant 3, implementor 41
Info : SCROD.cpu.1 rev 0, partnum c09, arch f, variant 3, implementor 41
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x00000193 pc: 0xffffff34
MMU: disabled, D-Cache: disabled, I-Cache: disabled
target halted in ARM state due to debug-request, current mode: System
cpsr: 0x2000019f pc: 0xffffff28
MMU: disabled, D-Cache: disabled, I-Cache: disabled
successful!
programming elf file on carrier0...
programming elf file on carrier1...
programming elf file on carrier2...
programming elf file on carrier3...
programming elf file on SCROD...

Note:  If the boardstack is not powered, you will get many "Error: Invalid ACK (0) in DAP response" messages.

[optional] Then check how much power is being drawn:
xrm@xrd04rp2:~$ pdu.sh 
  [on] He box pwr
  [on] Boardstack
80.0 W total
Goto page 1, 2   Next  All
ELOG V3.1.5-3a5f2f0