search

cms-gem-daq-project / ctp7_modules

0 stars 13 forks source link

[ Bug ]: Function scaADCCommand unable to read temperature channels of SCA ADC #118

Closed ram1123 closed 5 years ago

ram1123 commented 5 years ago

Brief summary of issue

While reading the SCA ADC channels corresponding to temperature, it gives Bus error corresponding to node node: GEM_AMC.SLOW_CONTROL.SCA.MANUAL_CONTROL.SCA_CMD.SCA_CMD_EXECUTE

I was trying to implement #100, to read one/all SCA ADC channel. I am able to read all other channes except those corresponding to the temperature. Thus, there is some issue only with channes that corresponds to temperature.

Types of issue

Expected Behavior

Current Behavior

Steps to Reproduce (for bugs)

  1. Checkout code from 834dd83675a3de1239ea6b431d761837fcda7007

  2. If you run the module readADCCommands. Then one should get

     [rasharma@gem904daq01 bin]$ ./blaster eagle34 08 0x200
 calling amc.readADCCommands on eagle34 with 8 and 512...done!
 RPC ERROR:memsvc error: Bus error accessing 0x66c0400c

    The corresponding rpcsvc message should be:

    Apr 15 10:45:39 CTP7 local0.notice rpcsvc[5827]: rpcsvc: Client connected from 192.168.0.180
Apr 15 10:45:39 CTP7 local0.info rpcsvc[5827]: amc:  Memhub initialized a semaphore. Current semaphore value = 1
Apr 15 10:45:39 CTP7 local0.info rpcsvc[5827]: amc.readADCCommands: DEBUG: 1: Function readADCCommands
Apr 15 10:45:39 CTP7 local0.info rpcsvc[5827]: amc.readADCCommands: DEBUG: 2: Optohybrids to read: 200
Apr 15 10:45:39 CTP7 local0.info rpcsvc[5827]: amc.readADCCommands: DEBUG: 3: Name of ADC Channel to read: 8
Apr 15 10:45:39 CTP7 local0.info rpcsvc[5827]: amc.readADCCommands: write memsvc error: Bus error accessing 0x66c0400c
Apr 15 10:45:39 CTP7 local0.info rpcsvc[5827]: amc.readADCCommands: DEBUG: 5: scaADCCommandOutput for OH0 = 0 
Apr 15 10:45:39 CTP7 local0.info rpcsvc[5827]: amc.readADCCommands: DEBUG: 5: scaADCCommandOutput for OH1 = 0 
Apr 15 10:45:39 CTP7 local0.info rpcsvc[5827]: amc.readADCCommands: DEBUG: 5: scaADCCommandOutput for OH2 = 0 
Apr 15 10:45:39 CTP7 local0.info rpcsvc[5827]: amc.readADCCommands: DEBUG: 5: scaADCCommandOutput for OH3 = 0 
Apr 15 10:45:39 CTP7 local0.info rpcsvc[5827]: amc.readADCCommands: DEBUG: 5: scaADCCommandOutput for OH4 = 0 
Apr 15 10:45:39 CTP7 local0.info rpcsvc[5827]: amc.readADCCommands: DEBUG: 5: scaADCCommandOutput for OH5 = 0 
Apr 15 10:45:39 CTP7 local0.info rpcsvc[5827]: amc.readADCCommands: DEBUG: 5: scaADCCommandOutput for OH6 = 0 
Apr 15 10:45:39 CTP7 local0.info rpcsvc[5827]: amc.readADCCommands: DEBUG: 5: scaADCCommandOutput for OH7 = 0 
Apr 15 10:45:39 CTP7 local0.info rpcsvc[5827]: amc.readADCCommands: DEBUG: 5: scaADCCommandOutput for OH8 = 0 
Apr 15 10:45:39 CTP7 local0.info rpcsvc[5827]: amc.readADCCommands: DEBUG: 5: scaADCCommandOutput for OH9 = 1411319934 
Apr 15 10:45:39 CTP7 local0.info rpcsvc[5827]: amc.readADCCommands: DEBUG: 5: scaADCCommandOutput for OH10 = 0 
Apr 15 10:45:39 CTP7 local0.info rpcsvc[5827]: amc.readADCCommands: DEBUG: 5: scaADCCommandOutput for OH11 = 0 
Apr 15 10:45:39 CTP7 local0.notice rpcsvc[5827]: rpcsvc: Client disconnected cleanly
  3. To check from which node this issue arising, I did following: 
    eagle34 > readAddress 0x66c0400c
0x66c0400c      node:  GEM_AMC.SLOW_CONTROL.SCA.MANUAL_CONTROL.SCA_CMD.SCA_CMD_EXECUTE
0x66c0400c     0x00000000
eagle34 >
  4. The issue is arrising from line 280-282, where it goes to function scaADCCommand. There might be an issue from scaADCCommand function.
  5. One important point is that the function scaADCCommand is successfully able to read all other channels (connected one) mentioned here https://github.com/cms-gem-daq-project/ctp7_modules/blob/49c40dbcbdf070fd38372f6435678d911eb60f0f/include/amc/sca_enums.h#L234-L265.

Possible Solution (for bugs)

Context (for feature requests)

Without this we will not be albe to access the temperature information as requested in #100. ## Your Environment
jsturdy commented 5 years ago

What would be best would be if you could get debugging info for a successful transaction, an unsuccessful transaction, and then subsequently the first transaction, which I understand would now fail after the unsuccessful transaction. What would be useful would be:

jsturdy commented 5 years ago

@ram1123, one thing that you also need to ensure is that the current source is only enabled for the channels that require it, and that it is disabled at the end of the routine, after the ADC sampling has finished

ram1123 commented 5 years ago

@jsturdy : Somehow today its able to read the temperature SCA-ADC channel without any error. My code is exactly same as the previous version. So, I should get the same issue while accessing the temperature channel. Is there any other changes made that can affect this?

jsturdy commented 5 years ago

It may be that the bad state the HW was in resulted in these instabilities... but I can't say for sure