Procedure to Load DSP on TDRs using JMDC Flash

The purpose of this method is to overcome the problem of limited bandwidths while AMS is on ISS if one wants to load a new DSP code on the 192 T DRs. The idea is that the JMDC flash should contain two command files which can be executed from ground. Writing command files from ground in the JMDC Flash can be done while DAQ is still running. Executing the files obviously requires DAQ is stopped.

Executing the commands to load a new software in the TDRs directly from the JMDC Flash minimizes the time DAQ is stopped.

In the current state, the procedure has been shown to work properly but it is still work in progress, essentially in the sense one needs to optimize the reading of the replies from the execution of the procedure in order to track quickly where eventual errors come from.

To follow this procedure, one should be familiar with the DAQ documents summarizing Data Types and Node Addresses as well as A. Kounine's document about xDR and JINx nodes. They can all be found at http://ams.cern.ch/AMS/DAQ/amsdaq.html.

For other sub-detector people, examples of the scripts used in this procedure can be found in pcpoc08 at /pocchome/tracker/saouter/ in the directory ExamplesProcedure.

1. Preparing the command files for JMDC

The two command files which will need to be uploaded on the JMDC Flash obey a Parent/Children hierarchy. The Children File ("__TDR_FW.cmd") contains a single command for writing the software inside a specific TDR. It is thus the file that contains the dsp code.

The Parent File, ("UPD_TDR.cmd") contains 192 times a command (Data Type 1F058C) to execute the "__TDR_FW.cmd" Children with a new node address. Executing the Parent File from ground will basically write the new firmware in all TDRs.

The Parent File should remain always on the JMDC Flash. When one wants to load a new DSP code to the TDRs, it is only needed to upload the Children containing the new firmware to JMDC.

Producing the Children

  1. The easiest way is to create an envelope that will further be sent with the Lebedev "my-tttt" command:

    Create a file with inside

    BEGIN_CMD_FILE: __TDR_FW.cmd ------------// This will give the name __TDR_FW.cmd to the file in JMDC
    W 11A 5 @file_tdr_3a83.dat ------------------// where 11A is the address of the first TDR but the parent will change it to be run 192 times...
    END_CMD_FILE:

    And then upload this file in the JMDC using my-tttt, see section 3.

  2. You can also use the standard tools from JMDC Commander

    To produce the Children command file, go to the JMDCCommander Directory in pcpoc08 (/pocchome/tracker/TrackerUser/JMDCCommander).

    Copy in this directory the new firmware you want to load on the TDRs (from TDR DSP Codes section in the TWiki or from /pocchome/tracker/TrackerUser/AMSWireCommands/DSPCodes/).

    Use TDR_file_upload to produce the binary version of the dsp code attached to a writing command (the program was written by Paolo and modified in order to keep only the writing command).

    > TDR_file_upload file_tdr_3a83.dat

    The output is the file file_tdr_3a83.dat.bin. When you upload this file in the JMDC, you will give it the name "__TDR_FW.cmd", see section 3.

Producing the Parent File

It should already be present on the JMDC Flash but if you need to modify it, for instance to exclude TDRs, you can write your own little program using as example the program gen.C you can find in the JMDCCommander directory (gen_FS.C in tracker/TrackerUser/JMDCCommander/FlightSpare is another version which produces the commands for the current configuration of the flight spare).

> g++ -o gen gen.C

> ./gen>all_tdrs

The content of all_tdrs looks like this:

ex.: 0 0 JMDC-SELF 5F058C 5f5f 5444 525f 4657 2e63 6d64 Faa 11a

where:

  1. First 0: Ignore Error Flag if set to 1.
  2. Second 0: Do not send Reply to HK
  3. 5F058C: execute flash command file with new node address.
  4. 5f5f 5444 525f 4657 2e63 6d64: file name (here the children = "__TDR_FW.cmd")*
  5. Faa: Tag for commands in the file
  6. 11a: node address

*: to convert the file name, one might simply use root in the following way (remember the name on JMDC is always 12 characters. A name with less than 12 characters will be right justified):

  • root > char name[13]="__TDR_FW.cmd";
  • root > for(int i=0;i<6;i++) printf(" %02hx%02hx",name[i*2],name[i*2+1]);printf("\n");
  • 5f5f 5444 525f 4657 2e63 6d64

Now use main to produce the loadable file.

> main all_tdrs.txt all_tdrs

The output is the file file.dat. As previously mentioned, this file should already be present on the JMDC Flash. It is renamed "UPD_TDR.cmd" when transferring it to JMDC. THIS FILE PROBABLY IS ALREADY (IT DOESN'T CHANGE) ON THE JMDC SO YOU DON'T NEED TO UPLOAD IT!!!

2. Preparing AMS Envelopes

The advantage of using the AMS envelope to send commands to be executed by JMDC (w.r.t. sending a set of single commands to JMDC) is to have the whole set of commands executed only when the whole envelope is delivered to JMDC (in the other approach, when you send a command, it will be executed but then you can lose the communication and not be able terminate the procedure).
Two envelopes must be sent for the complete procedure. An example of these envelopes can be found in the LoadSoftProcedure directory (ExecEnvelope_FM_1.com and ExecEnvelope_FM_2.com). The format of the commands in the envelopes respect the Lebedev structure and conventions of my-t commands (my-t, my-tt, my-ttt, my-tttt).

The file should be named with the extension .com and the structure of the file is the following:

Example.com.png

Check the directory AAL/SlowControl/JMDC (Tools from Alexei Lebedev) for the complete file example.com which shows many other features of AMS envelopes used with the my-tttt command.

Choose the name of the envelope keeping the ".lst" extension. Write your commands between "BEGIN_ENVELOPE:" and "END_ENVELOPE:". The first character is R or W and indicates if the command is a Read or Write Data Type. The second character is the node address (14 = JMDC-SELF, 11A = TDR-0-00). The third character is the command. Remaining characters are essentially the possible parameters for the command (see C. Xudong document for Data Types).

The envelope is sent with the my-tttt command, see section 4.

Preparing the envelopes

In the following examples, you will notice the use of Group Commands. Be aware that the use of Group Commands is a controversial matter for some people. This means that for other sub-detectors than Tracker, the commands in question can easily be separated into the number of commands necessary to address each node separately. An intermediate step for Tracker is to use group commands for each of the crates (instead of using only one group command addressing all TDRs at once).

The first envelope, (see attached file ExecEnvelope_FM_1.com) contains the following commands:

  1. SET_LST_HDR: 2000 -----------------------------------------------// From this point errors will be ignored
  2. W 68 7 3a83 ----------------------------------------------------------// Erase file 3a83 on TDRs
  3. SET_LST_HDR: 0000 -----------------------------------------------// From this point errors will NOT be ignored
  4. W 14 1F0207 000036B0 -------------------------------------------// JMDC wait 14 sec (make sure all files are erased)
  5. W 14 1F058B --UPD_TDR.cmd 0F11 ----------------------------// Execute command file UPD_TDR.cmd on JMDC flash
  6. W 14 1F0207 00011170 -------------------------------------------// JMDC wait 70 sec (writing can take some time)
  7. R 68 7 -----------------------------------------------------------------// Reading Flash Summary of all TDRs

Using a group command to address to all TDRs at once, step 1 erases the file 3a83 from all TDRs (necessary before writing if the file already exists in one TDR or if another file must be removed for space). Erasing can take in the worst case up to 14sec, which justifies step 2.

Step 3 executes the parent file present on JMDC. From the previous sections, the result of this is the writing of the firmware on all TDRs. Previous to loading the file on TDRs, it is appropriate to read the Flash of all TDRs to check the file has successfully been written. Step 4 uses again a group command to address all TDR nodes.

The second envelope (see attached file ExecEnvelope_FM_1.com) loads the file on all TDRs:

  1. W 68 0 3a83 ---------------------------------------------------------//Load File on all TDRs
  2. W 14 1F0207 00002710 -------------------------------------------//Wait 10 sec
  3. R 68 c -----------------------------------------------------------------//Get TDR Status

In Step 1, the Loading of the files can take a certain time. For safety, we use a 10sec wait in Step 2. Step 3 reads the TDR status and the reply must be analyzed to check the procedure is in fact successful. In case of errors, one will essentially need to analyze the replies to the execution of commands in the block files.

To load a new firmware, edit the current envelopes by changing the name of the firmware (e.g. 3a93 instead of 3a83).

3. Uploading the files on JMDC

jftp command

The standard method is using the jftp command.

e.g.:

> jftp -h pcgsc13 -p rs422 -n c -u file.dat -f __TDR_FW.cmd

Type jftp-? to understand options of jftp command. Options are:

  • --debug debug: Bigger is more.
  • {-h --host}: host eAss server Host name or IP string
  • {-p --port}: port eAss server port name or number
  • {-s --segsize}: seg_size Segment length for transfer in byte (def: 4000)
  • {-f --name}: jname File name at JMDC (def: jap_test.img)
  • {-n --node}: node JMDC node address (def: 4)
  • --handle handle: Transfer handle (def: random)
  • {-d --download}: gname Download file and file (def: put)
  • {-u --upload}: gname Upload file and file (def: ~/jmdcfiles/jap.img)
  • {-e --exec}: Execute after uplink transfer (def: save)
  • {-c --continue}: Continue uncompleted transfer (def: new)
  • {-r --reset}: Force <RESET> flag to be set (def: false)
  • {-l --left}: Left adjust filename (def: right adjust)

However this method has its inconvenient in the fact it does not wait for the reply of a successful transfer of the file segments.

JMDC-FTP interface

There exists an interesting alternative to upload files into JMDC, using the Alessandro JMDC-FTP interface. However it is not sure yet how available Alessandro wants this interface to be. Andreas thinks we should however "popularize" it to all uploads. This implies some small modifications I need to discuss with Alessandro when I come back in Geneva. One of the advantages is the control you have of time-out for the response when transferring the segments of file. Basically, the file is "printed" on the JMDC flash without it's content and then follows the content transfer.

Procedure to use the JMDC-FTP interface:

  1. The first step is to copy the two command file in /home/ams/basili/file-library/Command-file/ with the names you want them to have in the JMDC flash, this means UPD_TDR.cmd and __TDR_FW.cmd for the Parent and Children file respectively.
  2. Launch the program: JMDC-FTP eas:[port] [server]
  3. Select correct node address for the JMDC where you want to upload files (JMDC-SELF should in principle always work).
  4. Get Status to see last transfer done.
  5. Get the correct directory and select the file you want to transfer.
  6. Select Segment Size for the transfer (512 bytes is a nominal value recommended by P. Denett during previous tests).
  7. Open Transfer for the chosen file
  8. Write the file (right click to transfer all segments in continuous)
  9. Get Status

For a 25000 bytes file (typical size of the file containing the DSP code for Tracker), you expect an upload time of about 24 min when selected segment size for transfer are 512 bytes.

4. Executing the envelopes

Set the command path correctly, for example: set-command-path eas:hosc pcposk0 100 (or edit the command_path.conf file). The value 100 sets a timeout of 100s to wait for the reply. This might need to be adjusted according to undergoing conditions.

First DAQ should be stopped.

The execution is done with the my-tttt command:

> my-tttt ExecEnvelope_FM_1.com

For this execution, remember the extension must be ".com".

You might want to save the reply to the reading of TDRs flash: my-tttt ExecEnvelope_FM_1.com | tee reply1.txt

One still needs to develop the tool to analyze efficiently the reply of both envelopes execution to track rapidly where eventual errors come from. This is an issue essentially for tracker where 192 replies must be checked and a single error is difficult to trace.

With no errors in the first execution, you can proceed with the second envelope which is sent in the same way:

>my-tttt ExecEnvelope_FM_2.com

Again, to save replies in a text file: my-tttt ExecEnvelope_FM_2.com | tee reply2.txt.

Analyzing the Replies

The simple check proposed here is clearly not optimal yet!

To make sure to get the whole reply in the reply*.txt file, one must set a sufficient timeout for the reply in the command_path.config. Typically, 100s should be enough:

> set-command-path eas:rs422 pcgsc13 100

What you need to do is essentially check that for the first reply the firmware is present on the 192 TDRs. This means the reply must contain at least 192 times the filename, for example 2a73 is you have used the file_tdr_2a73.dat. Thus one easy way to check this information is using grep:

> grep -o 8a83 reply1.txt | wc -l

The result should be at least 192 if the file has been written successfully 192 times. However the file name can also appear in other places than the reply to the "Read flash Summary" command in the reply1.txt file (meaning more than 192 instances which can end up to be confusing). The best way is thus to also check the content of the reply to make sure how many other instances there should be (see complete file in attachment, reply1.txt, and the Into Details page).


Procedure to Load DSP on JINFs using JMDC Flash

An identical procedure as for TDRs can be used for the JINFs. Here were used:

  1. The same TDR_file_upload
  2. genJinfP.C and genJinfS.C (in place of gen.C) for Primary and Secondary JINFs (i.e. A and B brothers depending on the DAQ configuration)
  3. all_jinfP and all_jinfS (in place of all_tdrs)
  4. JINFT_FW.cmd (in place of __TDR_FW.cmd)
  5. UPDJINFP.cmd and UPDJINFS.cmd (in place of UPD_TDR.cmd).
  6. ExecEnvelope_FMJINFP_1.com, ExecEnvelope_FMJINFS_1.com, ExecEnvelope_FMJINFP_2.com and ExecEnvelope_FMJINFS_2.com (in palce of ExecEnvelope_FM_1.com and ExecEnvelope_FM_2.com)

-- PierreSaouter - 22-Jan-2011

-- MatteoDuranti - 12-Nov-2010

Topic attachments
I Attachment History Action Size Date Who Comment
PNGpng Example.com.png r1 manage 26.4 K 2010-11-08 - 14:54 PierreSaouter Example file.com
Unknown file formatcom ExecEnvelope_FMJINFP_1.com r1 manage 0.4 K 2010-11-12 - 05:21 MatteoDuranti  
Unknown file formatcom ExecEnvelope_FMJINFP_2.com r1 manage 0.2 K 2010-11-12 - 05:22 MatteoDuranti  
Unknown file formatcom ExecEnvelope_FMJINFS_1.com r1 manage 0.4 K 2010-11-12 - 05:22 MatteoDuranti  
Unknown file formatcom ExecEnvelope_FMJINFS_2.com r1 manage 0.2 K 2010-11-12 - 05:23 MatteoDuranti  
Unknown file formatcom ExecEnvelope_FM_1.com r1 manage 0.5 K 2010-11-12 - 05:20 MatteoDuranti  
Unknown file formatcom ExecEnvelope_FM_2.com r1 manage 0.2 K 2010-11-12 - 05:21 MatteoDuranti  
Texttxt all_jinfP.txt r1 manage 0.5 K 2010-11-12 - 05:30 MatteoDuranti  
Texttxt all_jinfS.txt r1 manage 0.5 K 2010-11-12 - 05:30 MatteoDuranti  
Texttxt all_tdrs.txt r1 manage 11.5 K 2010-11-12 - 05:30 MatteoDuranti  
C source code filec gen.C r1 manage 0.4 K 2010-11-12 - 03:47 MatteoDuranti  
C source code filec genJinfP.C r1 manage 0.4 K 2010-11-12 - 05:31 MatteoDuranti  
C source code filec genJinfS.C r1 manage 0.4 K 2010-11-12 - 05:38 MatteoDuranti  
Texttxt reply_1.txt r1 manage 5.1 K 2010-11-11 - 15:00 PierreSaouter Reply to the execution of the first command.
Edit | Attach | Watch | Print version | History: r20 < r19 < r18 < r17 < r16 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r20 - 2011-01-22 - PierreSaouter
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    Main All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback