VREF error on XC43 Enable

There is no delay in setting the VREF error, as soon as the expansion reports a VREF error, the corresponding inputs are set to error state and the dialog and log entry are triggered.

It sounds as if the VREF-A might be temporarily overloaded when powering up the XC43, causing the VREF error. The VREF:s are rated to 150 mA, maybe the inrush when powering up the sensors exceeds this level? I'd recommend measuring the current at power on and consider moving some sensor supplies to VREF-B.  

The part that have me confused is why disabling the module in IQANdesign didn't mask this error, as you say that you have a delay time between powering up the XC43:s and enabling the module in the application. 

If you look at the blink code on the XC43 right after it is powered up, before it is enabled in the application, do you see an error blink? 

Here's a trace of the error coming up. I noticed that even though the enable bit ("System is Ready") is set, there are a few other XC43 items with a "Disabled" status. after 1 cycle (60ms), the modules read OK. I've tried shorter cycle times and still have these errors.

The MDGN readings for temperature and +BAT measurement aren't sent every cycle like the I/O channels, so these MDGNs will come back with one module per cycle. 

Thanks,

I should be well below the 150mA on both modules. One module only has a single 12.5mA(Max Current) IQAN-SP pressure Sensor connected and it's still throwing the error.

I would also tend to agree that regardless of that fact, if the inrush was too high, I shouldn't see any inrush effect when delaying the enabling of the module, unless it's picking up a stored blink code.

I will investigate to see if there's an error code before enabling.

Side Note: If I power up the XC43 modules with the MD4, I do not get the error. I only get the error if the MD4 has started for at least 5 seconds before enabling the XC43s....

Would just like to add that there is no blink error code when the XC43s have power but before being enabled.

Another thought, do you have other master modules in the system than the MD4 ? If so, what master module is it that has the XC43 expansion? 

In multimaster systems, there is a function that delays error dialogs until the display module (or modules) come online. 

The system only has an MD4 master, 2 XC43s, a G11, and a J1939 engine. Thanks.

I've tried various methods to make the error go away and no success so far. 

I've checked the VREF voltage before, during, and after initialization of the module, but after powering it up and I get a solid 5.00V on my multimeter.

Thanks. With a multi master system, there is a function to withhold dialogs until all displays are online, with a single master MD4 there is no such function.

Thinking about this, it could be interesting to check the system log when you power the XC4 modules together with the MD4.

If you have the VREF glitch when the XC4 is powered up, before the MD4 GUI is started, you will not see the dialog. But it should be captured in the system log.

Maybe that could explain why you do not see the VREF error when the MD4 and expansion modules power up together?

For a short glitch, it could be hard to spot it with a multimeter. I'd recommend checking with a scope also.

Other than overloading the individual VREF, low supply to the module can also cause VREF error, if the supply drops just to the level where the 5V stops working, without dropping so low that CAN fails or the module restart.

Moved topic to hardware. I am not sure at all, but it sounds as if this VREF error could be an effect of a very brief supply dip. 

Hi Gustav, thanks for trying.

 I did do some testing and found if I disconnected the VREF supplied sensors (IQAN-SP500 actually), the system would start up fine and enable the modules without error, but as soon as I manually connected one sensor after enabling, the system would yell at me with a VREF error.

I ended up just booting them up at the same time as the MD4. Not ideal for this application, but workable. Would be nice to have some sort of delay option in having these system messages come up in the future.