Project

General

Profile

Bug #24646

Incorrect values at Pressure Transducer Readback

Added by Shrividhyaa Sankar Raman 4 months ago. Updated 16 days ago.

Status:
Resolved
Priority:
Normal
Start date:
07/22/2020
Due date:
% Done:

100%

Estimated time:
Spent time:
Duration:

Description

  • Display value received from FFPGA.
  • The value received from FPGA is zero.
PTReadbkB.JPG (264 KB) PTReadbkB.JPG Cavity B Shrividhyaa Sankar Raman, 11/17/2020 03:02 PM
PTReadbkA.JPG (265 KB) PTReadbkA.JPG Cavity A Shrividhyaa Sankar Raman, 11/17/2020 03:02 PM

History

#1 Updated by Shrividhyaa Sankar Raman 4 months ago

  • Ed suggested that we use the debug terminal on the LV panel to check if the registers are populated.
  • Checked for the output of parameter 136 (CA Pressure Transducer Reading) -> Output 0 as expected.
  • Checked for the output of parameter 135 (CA PT Readback) -> Output 0 which means the readback registers are not populated with the right values.
  • Checked other similar parameters to which changes have not been made -> still 0.
  • Parameters such as Saturation flags and Track and Hold state are old parameters that have not changed their values in sometime.
  • TODO: Look at the firmware to check there is anything in particular that has to be altered for the FPGA to sent the right values to the ARM.

#2 Updated by Brian Chase 4 months ago

Are there any updates on this bug?

#3 Updated by Shrividhyaa Sankar Raman 4 months ago

  • The PT Readback was tested for issues wrt LV and compared with earlier version of LV (Ed's version as the Sat flags work in his case).
  • Tried to write a value to the register and to see if it reflected on the output.
  • The output was still 0, however, the previously sent value does seem to show up as the value entered.
  • This is because, this register cannot be written to and only read.
  • Next, tried to write a default value to the code by specifying the default value in the spreadsheet.
  • Output still remains 0.
  • The FPGA is constantly writing 0s to ARM memory and this is seen in LV.
  • Would be helpful to determine cause by uploading default value from F/W.

#4 Updated by Shrividhyaa Sankar Raman 17 days ago

  • Steps were retraced to mimic the steps followed for the FW version and Date & Time registers.
  • It was found that apart from adding these to the firmware and re-running the Qsys (to generate the .dtb file), the front-end had to be altered to make a copy of the variable on the ARM side to update it on LV, every DAQ cycle.
  • A sample of the output has been attached below for both CAv A and Cav B.

#5 Updated by Shrividhyaa Sankar Raman 16 days ago

Steps followed to solve this issue:-
  1. Changes in F/W: * Added the 2 PIO registers at address offsets 0x140 and 0x150. * Generated Qsys * Used the utility to create soc_system.h file * Used the BSP editor tool to create the new preloader file (preloader-mkpimage.bin) * Using the xml files and the sopc_info file to create the .dtb
  1. Changes in S/W: * In DAQ thread, read the newly created registers. * Place the read value in sys object. * Add this to update list. * Added new soc_sys.h to the software before compiler. * The DAQ callback initially written for this parameter was removed (since this is no longer used). * This was compiled to generate the executable.
  1. No changes in LV
  1. Copied the files mentioned below to the SDCard: * llrf.rbf * preloader-mkpimage.bin * soc_system.dtb * meson_ts1_tcp * Spreadsheet

Also available in: Atom PDF