Please log AMC13 test activity below, blog style (new entries at top)

2012-08-06, hazen

Download Jeremy's HEAD version from 8/2/12. Compile 3 test BIT/MCS files:

  • Default (jumper/flash set IP address)
  • Fixed I/P address
  • Fixed I/P address

Flash the 1.34 version. Responds to ping and mCTR2tool ok. Now try the fixed 115.254 version. Argh, the "reload" command once again doesn't work. Cycle crate power. It works... can talk to board at above IP.

Now try flashing the "default" firmware. "reload" works. Can still access at 115.254. Verify that SPI flash IP address is 1.32. Remove jumper J1204 and re-power. Still at 115.254 (sigh!). Maybe messed up compiling. Confusion: Slot 5 board had no J1204, but was installed in board in slot 11. Unplug slot 11 board altogether. Still get a ping response from 115.254.

Re-install J1204 jumper on slot 4 and re-power. Still get response from 115.254.

Compile new version with original code but jumper-controlled backup address changed from 115.254 to 115.240. Program this one to flash. (J1204 is installed). Do "reload". Responds at 115.240 as expected. Remove J1204 and re-power. Still at 115.240. Sigh.

Flash same firmware into other board. Same results.

Try setting IP address to (maybe 115 is somehow special). No change.

Per Jeremy's request, program the 0.4.03 version from the web page into slot 11 board. Once again "reload" doesn't work. Power cycle. Can't access the board at all.

2012-08-02, hazen

Re-flash '2012-07-16a' version into both modules. Fix a few bugs in AMC13DaqTest.exe so it can handle nested scripts correctly. Run a few tests with script AMC13DaqTest/test.amc and see same event size in both mCTR. More tomorrow.

2012-08-01, hazen

Porting to ISE 14. Removed cores defined in ipcore_dir and substitute ones from e-mailed by Wu. Import into ISE 14.1 and re-compile. Compiles OK and superficially works. However, seeing some discrepancies in event length between old and new firmwares.

2012-07-16, hazen

Merged changes are here: Now add them to project and re-compile. Program into two mCTR2 in slots 5, 11 at IP addresses and

2012-07-13, hazen

Wu has made some minor changes to the code to fix the link reset problem. His changes are here: but must be merged with my firmware from here:

I will start on this next week.

2012-07-12, hazen

Temporary solution to IP addressing: Assign a totally fixed address. In ctr2_uhtr1600.v just set ip_addr to a fixed value. Build two firmwares with addresses and The board now in slot 5 is 32 and slot 11 is 40.

DAQ links do not work with this firmware:

Will ask Wu for help.

2012-07-11, hazen

Add two lines below to UCF and recompile per Wu's suggestion:

  NET "*/DAQ_Link_wu/UsrClk" TNM_NET = "DAQ_UsrClk";
  TIMESPEC "TS_DAQ_UsrClk" = PERIOD "DAQ_UsrClk" 8ns HIGH 50%;

MiniCTR2 Programming:

(instructions below from MN)

  1) Program the 4.02 firmware bitfile from JTAG.
  2) mCTR2tool.exe -t uhtr
  3) select your device (1).  Then FLASH -> PROGRAM (you'll need an MCS file)
      If Wu's firmware is branched from ours after 3.01, then you can do this with Wu's firmware.
  To change the IP address, use the SPICFG menu of mCTR2tool. 

Here is what I did:

  • Generate MCS file with "generic parallel flash" and zero offset
  • mCTR2tool.exe -t uhtr
  • "FLASH" then "PROG"

Doesn't work. It's a 128M SPI flash. That works better!

IP Addressing is a problem. NAT-MCH doesn't seem to route packets to any addresses outside, even though the settings are now correct:

[cms2] /home/hazen/work/uHTR_Firmware > telnet
Connected to
Escape character is '^]'.

Welcome to NAT-MCH

nat> ifconfig
network interface nat0:
  IP address:
  broadcast address:

2012-07-10, hazen

Attempting to integrate Wu's DAQ link into uHTR 4.02 release under ISE 13.3 on VirtualBox on Eric's desktop machine.

  • Rename Wu's MiniCTR.vhd to DAQ_Link_wu.vhd and put in .../ctr2/ctr2_uhtr1600/DAQ_Path/ in project
    • Edit to remove chipscope stuff
  • Edit DAQ_Link.vhd to instantiate DAQ_Link_wu.vhd
  • Copy and add other sources:
    • Add CRC16D16.vhd
    • Add Hamming.vhd
    • copy ipcore_dir tree
    • Add dataFIFO.ngc, DataBuf.ngc, TDP16_16.ngc, SDP16_16.ngc

2012-07-09, hazen

Basic DAQ event readout now seems to work. Have added several useful commands to my new tool AMC13DaqTest which is currently only in ~hazen/src/11_4_1.

HOWTO record test data

Log on to CMS1 as user daq and start DCCdiagnose.exe to control TTC system. Log on to CMS2 and run AMC13DaqTest.exe. For now:

  $ source ~hazen/
  $ /src/11_5_1/hcal/hcalUpgrade/amc13/bin/linux/x86_64_slc5/AMC13DaqTest.exe

cms1 (DCCdiagnose.exe) cms2 (AMC13DaqTest.exe)Sorted ascending Notes
  AMC Link status: 04100410 Display AMC13 status
  Ctrl 0: 03000001 Display AMC13 status
  Ctrl 1: 000e0001 Display AMC13 status
  df test.dat Dump events to file
  en 5,11 Enable AMC inputs (will change to 0,10 at some point). Also resets AMC13
  LSC Link Down Display AMC13 status
  Mon buffer page: 00000000  Evts: 0000000a  words: 00000712 Display AMC13 status
ttc/trig 4   Disable TTC triggers (set to VME control only)
ttc/cmd 2   Issue TTC Event Count Reset command
ttc/l1a 10   Generate 10 triggers
  run mode Display AMC13 status
  st Display AMC13 status

You can dump the file in hex as follows:

   $ od -Ax -t x8 test.dat | less
   000000 00000712deadbeef 51000001c8c00008
   000010 000000059af5ddb0 000e041000000010
   000020 0000000000000000 000000000000c701
   000030 0000c70100000000 0800800000000401
   000040 0007000600058c8c 000b000a00090008
   000050 000f000e000d000c 0013001200110010
   000060 0017001600150014 001b001a00190018
   000070 001f001e001d001c 0023002200210020
   011af0 06f306f206f106f0 06f706f606f506f4
   011b00 06fb06fa06f906f8 705f06fe06fd06fc
   011b10 0000000000000a00 a00003891aca0000

2012-07-08, hazen

New firmware version 0xe. Still see problem#2 below. Investigating.

2012-07-07, hazen

Trying to reproduce a DAQ firmware problem.

Test #1 - failure to reset

(set Xilinx board to deliver fast triggers at 20kHz)

cms1 (DCCdiagnose.exe) cms2 (AMC13Tool.exe) Notes
ttc/trig 1   Enable triggers
ttc/trig 4   Disable triggers
  wv 3 410 Enable AMC inputs
  wv 1 1 Set run mode
  wv 0 1 Reset all
  rv d Read word count
  0xd 0x712 FAIL: Should be zero!
  wv 0 1 Reset all
  rv d Read word count
  0xd 0 Always zero 2nd time

This fails intermittently.

Test 2 with AMC13DaqTest.exe

cms1 (DCCdiagnose.exe) cms2 (AMC13DaqTest.exe) Notes
  en 5,11 Enable AMC inputs 5, 11 and reset AMC13
ttc/cmd 1   Reset EvN to 1
ttc/l1a   Make one trigger
  rd Read and display event
  ne advance to next event
ttc/l1a   Make trigger
  rv 0x4000 10 See corrupted data

This fails consistently:

It is probably a software problem, but it seems that I am competing for use of the TTC system so stop for now.

2012-07-05, hazen

Debugged AMC13 event readout code, added file dump feature to Discovered a firmware issue which causes data to appear incorrect after the first event, reported to Wu.

E-mailed Jeremy to ask about word order question.

2012-07-01, hazen

Install new release 11_5_0 in daqowner. Do not set as default yet. Oops, 11_5_0 is buggy. Update immediately to 11_5_1 and make it the default.

2012-06-29, hazen

Checked in to CVS several updates of work done with Charlie.

HyperDAQ were updated to include Charlie's new HyperDAQ. This required substantial changes to the address tables. These changes were done to the existing files AMC13_AddressTable_S6/V6.txt.

Run Control were updated to add startRun(), endRun(), AMCInputEnable(), nextEventSize(), readNextEvent().

2012-06-27, rohlf

Fix AMC13Tool to support hex version names in firmware files. Fork address tables with names AMC13_AddressTable_S7/V8.txt. FIXME: This address table is now incompatible with the one used by the rest of the software!

2012-06-12, hazen

First release firmware and instructions for DAQ in AMC13:

to set up L1A:
set L1a to about 20KHz
start dccdiagnose.exe
ttc/trig 4(turn off L1A)

run amc13tool
wv 3 410 (enable amc5 and amc11)
wv 1 1 (set run bit)
wv 0 1 (reset all)

ttc/cmd 0x28(reset orbit number)
ttc/trig 1 (enable L1A)

this will take 0x800 events in the memory and throw away all when the buffer is full.

In general, the initialization  and read out remains basically the same as with DCC2.

2012-05-24, rohlf

Sucessfully updated Spartan firmware from v3 to v6 at point 5. This was accomplished remotely in Bat. 40 at CERN with AMC13Tool by first writting Spartan v6 to flash at 0x000000 (its old location) as if programming the Header, power cycling the AMC13 module with the NAT tool, reprogramming the flash Header (0x000000), Golden (0x100000), Spartan (0x200000), and Virtex (0x400000), and then issuing the software command to reconfigure from flash.

2012-05-24, rohlf

Update firmware in cDAQ lab at CERN using python software. Older software (now named amc13_python_backup-23-may2012) was used to program Spartan firmware v6 into 0x0, power cycle crate, program Header (0x000000), Golden (0x100000), Spartan (0x200000), and Virtex (0x400000) where in the process a bug was discovered in programming the header due to incorrect erase of a single page, power cycling again, and verifying the configuration.

2012-04-27, hazen

Install HCAL xDAQ 11.4.0 (as daqowner) per instructions:

To install on a teststand (as daqowner) :
      perl installDAQ_11_4_0.perl --mode=teststand
      ~daqowner/common/bin/ (choose 11.4.0)

You can make a code-development area on a teststand or USC using
      perl installDAQ_11_4_0.perl --mode=[teststand|usc]
--ownsource=${HOME}/src/11_4_0 --packages=hcalUpgrade --cvsuser=[your afs id]
You can list multiple packages, separated by commas.

2012-01-10, hazen

Trying to program a new AMC13 MMC. Plug in to crate, connect JTAG ICE 3 cable to JTAG connector. Fails to program. Try to force power on with "pwr_on 9" (it's in AMC slot 4) but doesn't help.


  pwr_on [fru #]
  pwr_off [fru #]

  where [fru #] is the fru number starting with 5 to16. That means if you
  want to switch on e.g. AMC2 use the command "pwr_on 6".

Remembering wisdom of Tom Gorski:

    Maybe grasping at straws here, but if you look at the reset circuit for the AVR on the MMC schematic page, you see that it is important for the IPMI_ENABLE# line to be driven low, in order to release reset. You didn't say what your power situation was to the card. If you had it in a rig with an MCH trying to talk to the card, then the IPMI_ENABLE# line would indeed be zero, and the FET would not be pulling reset low, and the problem is probably somewhere else. On the other hand, if you have the card in a rig with a dumb power supply, then AVR reset will be pulled low unless a shunt is installed at JMP4. Since reset goes to the JTAG connector you might be able to check this with a voltmeter.

This should be taken care of by the uTCA backplane, no? Meanwhile, trying to program the thing in Wu's test fixture. Doesn't work. Checking to be sure jumpers are installed. AHA ... the required ECO (soldered wire) on the T3 board was missing. Now all is OK. One can indeed program the MMC on a new board in a MicroTCA crate.

Another observation: an AMC won't power up fully without the front panel hardware installed, as the handle switch must be depressed for the negotiation with the MMC to complete.

2011-12-06, heister

cms2: SLC5 updated, installation fine tuned, PyChips and microHAL installed for the "daq" user, all tested and works

2011-12-06, hazen

Install 2nd NIC on cmssun2 (old Dell computer, Ubuntu 10.04 OS). Cable to AMC13 in uTCA crate. Install IPBus test firmware from Wu. Install PyChips. Works! (I think).

Added AMC13FlashProgramming page.

2011-12-02, hazen

Started this log. One dead NAT-MCH at Boston. 2nd NAT-MCH shipped from MN by Jeremy.

Reset I/P address to and connect to CMS1. One can now do cms1> telnet But, this MCH has firmware v2.0 which doesn't work with AMC13 (symptom is both red/green LEDs blink forever on AMC13 with MMC firmware V1.2).

Updating MCH firmware to V2.10 received from NAT on 9/20/11. Briefly, the procedure is:

  unzip the e-mail attachement somewhere
  copy the "bin" file to /tftpboot/mch on
  connect to the MCH using the USB console and type "update_firmware" and follow the prompts
  type "reboot" to load the new firmware

It works! Now the AMC13 seems to be up and running with the MCH.

-- EricHazen - 02 Dec 2011

This topic: Main > TWikiUsers > EricHazen > CmsSlhc > AMC13DebugLog
Topic revision: r25 - 06 Aug 2012 - EricHazen
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback