Post Go back to editing

Receiving frequent VI_ERR_A in Alert Status Register of AD74412R

Category: Hardware
Product Number: AD74412R

I am currently conducting testing of an AD7441R. My test consists of using only Channel A, in Current Input, Loop Powered Mode. I have enabled short circuit protection. For my testing I am using a Fluke process meter to simulate the sensor. The Fluke meter is slowly ramping the current from 4.00 mA to 20 mA and back down again. My firmware performs a single conversion every 10 minutes. 

Normally the AD74412R properly measures the current as it changes. I am also monitoring the Alert Status register and have observed that I am often receiving a VI_ERR_A error. 

Here is a portion of my event log:

2000-01-01 08:30:31 -> AI00:17.612
2000-01-01 08:40:31 -> AI00:15.663
2000-01-01 08:50:31 -> AI00:9.898
2000-01-01 09:00:31 -> AI00:4.795
2000-01-01 09:10:31 -> AI00:10.697
2000-01-01 09:18:29 -> AD74412R Status Change. anAPI_Ref = 1, Notification = 17
2000-01-01 09:20:31 -> AD74412R Status Change. anAPI_Ref = 1, Notification = 17
2000-01-01 09:20:31 -> AI00:5.418
2000-01-01 09:30:31 -> AI00:11.396
2000-01-01 09:40:31 -> AI00:18.032
2000-01-01 09:48:15 -> AD74412R Status Change. anAPI_Ref = 1, Notification = 17
2000-01-01 09:50:31 -> AD74412R Status Change. anAPI_Ref = 1, Notification = 17
2000-01-01 09:50:31 -> AI00:4.646

Note that before the first status change message, the current was changing every 10 minutes (at 8:30, 8:40, 8:50, 9:00, and 9:10). The next conversion should occur at 9:20 and it did, but at 9:18 and at 9:20 I received notification of two errors. Those messages indicate that the VI_ERR_A bit was set in the Alert Status Register. The errors then cease for several minutes only to return again at 9:48.This happens over and over again during the test. 

It could be happening because of a problem in the Fluke meter. Or maybe it is happening because of some other reason. Do you have any thoughts or recommendations?

I think I will remove the fluke meter and install a suitable resistor in its place. This will cause a fixed current to flow. If the error then continues, it would point to a firmware / hardware problem. If it does not reoccur it would point to a problem in the Fluke meter. 

Please let know your thoughts today. I hope your response can help me determine testing I can perform over the weekend. 

Thanks for everything, 

Clark

Parents
  • Hi Clark,

    thank you for your query. It will be great to understand, if you are using AD74412R evaluation board or your own board. Could you please comment on this.

    Certainly you are going in correct direction with your experiments to debug this issue. As I am not fully aware of your setup, I will write you my thoughts, which might help you with debugging:

    Meaning of the VI_ERR_A in Current input, loop powered is as following (from datasheet): "Current input, loop powered: short-circuit error. A short to ground is detected if the digital input comparator is enabled as described in Current Input Loop Powered section with a trip point of AVDD/2 and the digital output is inverted via the INV_DIN_COMP_OUT bit in the DIN_CONFIGx registers. The debounce time of this error detect is user-programmable via the DEBOUNCE_TIME bits in the DIN_CONFIGx registers."

    Have in mind, short circuit error detection is in principle based on detecting screw terminal voltage. Once voltage drops below certain value, short circuit error is triggered. 

    It might be, that there are "short periods" when FLUKE demands more power for while... (if so, increasing debounce time in DEBOUNCE_TIME bits might help).

    Let me know, if you will need to answer any questions.

    Please keep me informed, once the issue will be solved.

    Regards,

    Arnost

  • I am using my own board. My test with a resistor proved the problem was the Fluke. That's good to know.

    But I still have a minor problem with another false short circuit detection. The AD74412R always throws a VI_ERR_A immediately after the first conversion. As far as I can tell, it never happens on any of the other conversions (unless the input is actually shorted).

    I have set the DEBOUNCE_TIME bits to 0x1F and that has not helped eliminate this error.

    Is it usual to get a false short circuit error with the first conversion after boot up? If so, is there any way to stop this from happening. This is a minor problem for me but if I can easily eliminate this error I would like to do so.

    Thanks for your help!

    Clark

  • Hi Clark,

    I will be happy to support you, however at the moment I am afraid I don't have enough information to replicate the setup.

    Could you please give me details as such:

    # Are you still in same mode Current Input, Loop Powered?

    # Can you please clarify, what you mean by "any of the other conversions", please? (Do you mean different output/input mode.)

    # Are you waiting enough time for all voltage sources to ramp up to their default values after bootup?

    # Have you tried to put some wait time, once mode is changed, before first conversion take place?

    Please let me know, if any of these helps. 

    Regards,

    Arnost

  • Arnost

    Here are the answers to your questions:

    1. I am always in Current Input, Loop Powered mode. I configure for that mode at startup and never change it.

    2. I instruct the chip to perform a single conversion at startup and every hour thereafter using the ADC Conversion Control Register, CONV_SEQ bits set to 01. This does not happen during initialization, but only once an hour after the system has been started. 

    3. When the system powers up the firmware boots. THE AD74412R power supplies are powered at this time. During boot up, the first task it to initialize the modem and then comms. This takes 15 seconds or so. After this the AD chip is initialized and the Loop powered current input mode is established for the channels. 

    4. Regarding the additional wait time, I will do this, but I am having difficulty  ascertaining exactly where the delay needs to be introduced. As mentioned earlier, during my modem setup I am not setting the CONV_SEQ bits. Those are set every hour in a routine called by the MCU's RTC. So I am currently having trouble understanding why the AD chip is performing a conversion right after it is initialized. I can see that something is causing the chip to assert the ADC_RDY lead but I haven't yet figured out what is causing this. When that happens, it causes an interrupt and which causes the firmware to read the ADC and transmit the values. Immediately after that I receive the short circuit detection. 

    Once I complete my testing, and get the system sent to my customer, I will investigate this further. I think I have the software and hardware diagnostic tools to determine what is going on. 

    Thank you for your assistance. It has been helpful!

    Clark

Reply
  • Arnost

    Here are the answers to your questions:

    1. I am always in Current Input, Loop Powered mode. I configure for that mode at startup and never change it.

    2. I instruct the chip to perform a single conversion at startup and every hour thereafter using the ADC Conversion Control Register, CONV_SEQ bits set to 01. This does not happen during initialization, but only once an hour after the system has been started. 

    3. When the system powers up the firmware boots. THE AD74412R power supplies are powered at this time. During boot up, the first task it to initialize the modem and then comms. This takes 15 seconds or so. After this the AD chip is initialized and the Loop powered current input mode is established for the channels. 

    4. Regarding the additional wait time, I will do this, but I am having difficulty  ascertaining exactly where the delay needs to be introduced. As mentioned earlier, during my modem setup I am not setting the CONV_SEQ bits. Those are set every hour in a routine called by the MCU's RTC. So I am currently having trouble understanding why the AD chip is performing a conversion right after it is initialized. I can see that something is causing the chip to assert the ADC_RDY lead but I haven't yet figured out what is causing this. When that happens, it causes an interrupt and which causes the firmware to read the ADC and transmit the values. Immediately after that I receive the short circuit detection. 

    Once I complete my testing, and get the system sent to my customer, I will investigate this further. I think I have the software and hardware diagnostic tools to determine what is going on. 

    Thank you for your assistance. It has been helpful!

    Clark

Children
No Data