PGA411Q1EVM: Why does PGA411-Q1 angle and velocity readout fail when FAULTRES is not kept LOW?

Hello Clancy!

@1: EEPROM handling is currently not implemented; I'm just writing to device registers (OVUV1 to OVUV6, TLOOP_CFG, AFE_CFG, PHASE_CFG, CONFIG1, CONTROL1, CONTROL2, CONTROL3, CLCRC, CRC,CRC_CTL1)
So I wouldn't expect a problem from that side.

@2: I check with an oscilloscope; there are no spikes at the NRESET pin. The FAULTRES pin is a little more wobbly, but are easily within the 70% bounds given in the datasheet.

@3: I increased the current limit on the power supply (from 350mA to 950mA @5V); now I see that the configuration is correct on the chip; but the readout of the angle is still only updated when I keep FAULTRES at LOW level.

I currently do as follows:
1) FAULTRES -> HIGH
2) NRESET -> 100us
3) 6ms wait for "self-init" of chip
4) toggle FAULTRES
5) DIAG Mode -> write config -> NORMAL MODE -> read config
6) verify read config vs. expected config; if as expected (the same), then force FAULTRES to LOW.
7) periodically read STAT4, STAT5, STAT6, STAT7 and config (just to check that it is kept)

with this sequence the angle in STAT5 is updated. If I skip step 6, I only get one angular value.

My configuration (CRC calculated for read addresses):

DEV_OVUV_1 = (CRC = 60, ResStatus = 0, OSHORTH = 0, OSHORTL = 0, EXTILIMTH_H1_2 = 5, EXTILIMTH_L1_2 = 5, EXTOUT_GL = 8, ADDR = 83)
DEV_OVUV_2 = (CRC = 40, ResStatus = 0, DVMSENL = 5, DVMSENH = 5, TRDHL = 3, XEXT_AMP = 0, res = 0, ADDR = 107)
DEV_OVUV_3 = (CRC = 52, ResStatus = 0, OOPENTHH = 7, OOPENTHL = 7, OVIZH = 3, OVIZL = 0, EXTOVT = 7, EXTUVT = 7, ADDR = 101)
DEV_OVUV_4 = (CRC = 16, ResStatus = 0, FSHORT_CFG = 0, nBOOST_FF = 1, VEXT_CFG = 0, AUTOPHASE_CFG = 0, TEXTMON = 7, TSHORT = 7, res = 0, ADDR = 236)
DEV_OVUV_5 = (CRC = 53, ResStatus = 0, res = 0, TOPEN = 7, res2 = 0, ADDR = 82)
DEV_OVUV_6 = (CRC = 61, ResStatus = 0, LPETHH = 3, LPETHL = 3, res = 0, BOOST_VEXT_MASK = 0, IZTHL = 7, res2 = 0, ADDR = 233)
DEV_TLOOP_CFG = (CRC = 27, ResStatus = 0, DKI = 4, SENCLK = 0, OHYS = 1, DKP = 4, MKP = 2, res = 0, ADDR = 166)
DEV_AFE_CFG = (CRC = 28, ResStatus = 0, GAINSIN = 1, GAINCOS = 1, res = 0, ADDR = 194)
DEV_PHASE_CFG = (CRC = 36, ResStatus = 0, PHASEDEMOD = 0, EXTOUT = 0, EXTMODE = 1, APEN = 1, PDEN = 0, EXTUVF_CFG = 0, ADDR = 87)
DEV_CONFIG1 = (CRC = 61, ResStatus = 0, MODEVEXT = 2, SELFEXT = 0, res = 0, NPLE = 0, res2 = 0, ADDR = 190)
DEV_CONTROL1 = (CRC = 16, ResStatus = 0, DIAGEXIT = 0, MEXTMON = 1, MAFECAL = 1, MIZUV = 1, MIZOV = 1, MEXTUV = 1, MEXTOV = 1, MFLOOPE = 1, MFOCOSOPL = 1, MFOSINOPL = 1, MFOCOSOPH = 1, MFOSINOPH = 1, res = 0, MFOSHORT = 1, res2 = 0, ADDR = 144)
DEV_CONTROL2 = (CRC = 37, ResStatus = 0, ENEXTUV = 0, ENEXTMON = 0, ENBISTF = 0, ENIOFAULT = 0, ENINFAULT = 0, RDC_DISABLE = 0, res = 0, LBIST_EN = 0, ABIST_EN = 0, ADDR = 99)

Status readout:
DEV_STAT1 = (CRC = 39, ResStatus = 0, FOSHORT = 0, FGOPEN = 0, STAT = 0, FOSINOPH = 0, FOCOSOPH = 0, FOSINOPL = 0, FOCOSOPL = 0, FLOOPE = 0, EXTOV = 0, EXTUV = 0, EXTILIM = 0, FTECRC = 0, FCECRC = 0, FRCRC = 0, FLOOP_CLAMP = 0, ADDR = 129)
DEV_STAT2 = (CRC = 0, ResStatus = 0, SORD = 0, SPRD = 0, res = 0, ADDR = 0)
DEV_STAT3 = (CRC = 16, ResStatus = 0, FIZH1 = 0, FIZH3 = 0, FIZH2 = 0, FIZH4 = 0, FIZL1 = 0, FIZL3 = 0, FIZL2 = 0, FIZL4 = 0, OMIZ1H = 0, OMIZ3H = 0, OMIZ2H = 0, OMIZ4H = 0, OMIZ1L = 0, OMIZ3L = 0, OMIZ2L = 0, OMIZ4L = 0, ADDR = 132)
DEV_STAT4 = (CRC = 31, ResStatus = 1, SOUTZ = 0, SOUTB = 1, SOUTA = 1, SFAULT = 0, IOFAULT = 0, FVDDOV = 0, FVCCOV = 0, LBISTF = 0, ABISTF = 0, FEXTMODE = 0, FTSD2 = 0, FVDDOC = 0, FBSTOV = 0, SPI_ERR = 0, FEXTMONL = 0, FEXTMONH = 0, ADDR = 31)
DEV_STAT5 = (CRC = 28, ResStatus = 0, ORDANGLE = 393, ORDCLOCK = 0, PRD = 0, res = 0, ADDR = 65)
DEV_STAT6 = (CRC = 62, ResStatus = 0, ORDVELOCITY = 16383, PRD = 0, res = 0, ADDR = 111)
DEV_STAT7 = (CRC = 17, ResStatus = 0, REVID = 3, OPTID = 1, DEVSTATE = 1, FAFECAL = 0, res = 0, ADDR = 225)

Controls:
DEV_CONTROL3 = (CRC = 5, ResStatus = 0, EXTEN = 1, LPEN = 1, SPIDIAG = 0, reserved = 0, ADDR = 221)
DEV_CLCRC = (CRC = 55, ResStatus = 0, ECCRC = 0, res = 0, ADDR = 79)
DEV_CRC = (CRC = 38, ResStatus = 1, RCRC = 122, res = 0, ADDR = 15)
DEV_CRCCALC = (CRC = 33, ResStatus = 0, CRCCALC = 122, res = 0, ADDR = 217)
DEV_EE_CTRL1 = (CRC = 24, ResStatus = 0, EECMD = 0, res = 0, ADDR = 227)
DEV_CRC_CTRL1 = (CRC = 53, ResStatus = 0, CRCCTL = 1, res = 0, ADDR = 122)
DEV_EE_CTRL4 = (CRC = 32, ResStatus = 0, EEUNLK = 0, reserved = 0, ADDR = 186)
DEV_UNLK_CTRL1 = (CRC = 2, ResStatus = 0, DEVUNLK = 240, res = 0, ADDR = 100)

BR,

Markus

Also, when you toggle FAULTRES back to high, what is the state of the FAULT pin?
When I keep FAULTRES high instead of low, the FAULT pin stays low (verified via osci over a period of ~1min, normal trigger, level 2.31V, rising edge)

Interesting: When I keep FAULTRES low after config verification (readback), the FAULT pin sometimes toggles for about 20us every 1ms with a period of 83ns (~12MHz) within this 20us.

SPI frames are ok on the oscilloscope. Change of data with rising edge, data valid for falling edge. I'm using 2.5MHz SPI CLK.
I disabled the continues CRC checking in the config.

NCS is toggling between SPI frames. It is 600ns high before the next SPI frame. This should be ok according to the datasheet.
What I additionally sometimes see is that the CS ans CLK lines partially toggle between SPI frames.
This would explain, that the chip sees incomplete SPI frames and signals SPI error. GND connection is checked (impedance in mOhm, voltage between ground 1-2mV (tolerance of meas. device).

The readout config I posted in Jun 23, 2017 7:10 AM is when I held FAULTRES LOW.

Maybe I sum up here to not get confused, what I can currently observe:

----- with no connection on the IZ* and OE* pins ("open") -----
- case 1: "keep FAULTRES LOW:"
  if I do that, I do not read any faults (SFAULT via SPI). EXTEN=1 and LPEN=1 are kept (I just run this case again >5min).
  In this state I'm able to read angle/velocity values as expected, but are not reasonable as no IZ*, OE* connection.
- case 2: "toggling FAULTRES once after config is verified (should be ok as the datasheet mentioned "deglitch" time; this is surely passed by then) and then keep FAULTRES HIGH until SFAULT detected:"
  I read SFAULT=1 in STAT4; when observed, I toggle FAULTRES (high-low-high, 100us in low). SFAULT is read as 0. But the exciter is disabled.
 Here I see FLOOPE=1, OMIZ1L=1 and OMIZ2L=1. Where I can confirm that OMIZ2L and OMIZ1L are set to 1 at the same fault.
  After some time, I only read SFAULT=1, but I see no change in STAT1 and STAT3; so I read error, toggle FAULTRES, but cannot say which error it is. When I reach this, EXTEN=0 an LPEN=0 and cannot be reactivated by writing to CONTROL3.

----- with connection on the IZ* and OE* pins -----
- case 1:
  as above, but angle/velocity values now make sense; EXTEN=1 and LPEN=1 are kept; (again tested >5min)
- case 2:
  angle/velocity readout ok; but the case that EXTEN and LPEN are disabled (set to 0) occurs, but from STAT1, STAT3 (and STAT4) I cannot say which error it was; there is only SFAULT=1.
  And EXTEN and LPEN cannot be re-enabled once they come to 0.

In both cases where the IZ* and OE* are connected I read the following config when EXTEN=0, LPEN=0:
(STAT1 and STAT3 are only read after SFAULT=1 is read first, but SFAULT=1 stays at 1 at this state)

      ConfReg = (
        DEV_OVUV_1 = (CRC = 60, ResStatus = 0, OSHORTH = 0, OSHORTL = 0, EXTILIMTH_H1_2 = 5, EXTILIMTH_L1_2 = 5, EXTOUT_GL = 8, ADDR = 83)
        DEV_OVUV_2 = (CRC = 40, ResStatus = 0, DVMSENL = 5, DVMSENH = 5, TRDHL = 3, XEXT_AMP = 0, res = 0, ADDR = 107)
        DEV_OVUV_3 = (CRC = 52, ResStatus = 0, OOPENTHH = 7, OOPENTHL = 7, OVIZH = 3, OVIZL = 0, EXTOVT = 7, EXTUVT = 7, ADDR = 101)
        DEV_OVUV_4 = (CRC = 11, ResStatus = 0, FSHORT_CFG = 1, nBOOST_FF = 1, VEXT_CFG = 0, AUTOPHASE_CFG = 0, TEXTMON = 7, TSHORT = 7, res = 0, ADDR = 236)
        DEV_OVUV_5 = (CRC = 53, ResStatus = 0, res = 0, TOPEN = 7, res2 = 0, ADDR = 82)
        DEV_OVUV_6 = (CRC = 61, ResStatus = 0, LPETHH = 3, LPETHL = 3, res = 0, BOOST_VEXT_MASK = 0, IZTHL = 7, res2 = 0, ADDR = 233)
        DEV_TLOOP_CFG = (CRC = 27, ResStatus = 0, DKI = 4, SENCLK = 0, OHYS = 1, DKP = 4, MKP = 2, res = 0, ADDR = 166)
        DEV_AFE_CFG = (CRC = 28, ResStatus = 0, GAINSIN = 1, GAINCOS = 1, res = 0, ADDR = 194)
        DEV_PHASE_CFG = (CRC = 36, ResStatus = 0, PHASEDEMOD = 0, EXTOUT = 0, EXTMODE = 1, APEN = 1, PDEN = 0, EXTUVF_CFG = 0, ADDR = 87)
        DEV_CONFIG1 = (CRC = 61, ResStatus = 0, MODEVEXT = 2, SELFEXT = 0, res = 0, NPLE = 0, res2 = 0, ADDR = 190)
        DEV_CONTROL1 = (CRC = 33, ResStatus = 0, DIAGEXIT = 0, MEXTMON = 0, MAFECAL = 0, MIZUV = 0, MIZOV = 0, MEXTUV = 0, MEXTOV = 0, MFLOOPE = 0, MFOCOSOPL = 0, MFOSINOPL = 0, MFOCOSOPH = 0, MFOSINOPH = 0, res = 0, MFOSHORT = 0, res2 = 0, ADDR = 144)
        DEV_CONTROL2 = (CRC = 59, ResStatus = 0, ENEXTUV = 1, ENEXTMON = 1, ENBISTF = 1, ENIOFAULT = 1, ENINFAULT = 1, RDC_DISABLE = 0, res = 0, LBIST_EN = 0, ABIST_EN = 0, ADDR = 99)
      StatReg = (
        DEV_STAT1 = (CRC = 39, ResStatus = 0, FOSHORT = 0, FGOPEN = 0, STAT = 0, FOSINOPH = 0, FOCOSOPH = 0, FOSINOPL = 0, FOCOSOPL = 0, FLOOPE = 0, EXTOV = 0, EXTUV = 0, EXTILIM = 0, FTECRC = 0, FCECRC = 0, FRCRC = 0, FLOOP_CLAMP = 0, ADDR = 129)
        DEV_STAT2 = (CRC = 0, ResStatus = 0, SORD = 0, SPRD = 0, res = 0, ADDR = 0)
        DEV_STAT3 = (CRC = 16, ResStatus = 0, FIZH1 = 0, FIZH3 = 0, FIZH2 = 0, FIZH4 = 0, FIZL1 = 0, FIZL3 = 0, FIZL2 = 0, FIZL4 = 0, OMIZ1H = 0, OMIZ3H = 0, OMIZ2H = 0, OMIZ4H = 0, OMIZ1L = 0, OMIZ3L = 0, OMIZ2L = 0, OMIZ4L = 0, ADDR = 132)
        DEV_STAT4 = (CRC = 42, ResStatus = 0, SOUTZ = 0, SOUTB = 1, SOUTA = 1, SFAULT = 1, IOFAULT = 0, FVDDOV = 0, FVCCOV = 0, LBISTF = 0, ABISTF = 0, FEXTMODE = 0, FTSD2 = 0, FVDDOC = 0, FBSTOV = 0, SPI_ERR = 0, FEXTMONL = 0, FEXTMONH = 0, ADDR = 31)
        DEV_STAT5 = (CRC = 53, ResStatus = 0, ORDANGLE = 1, ORDCLOCK = 0, PRD = 1, res = 0, ADDR = 65)
        DEV_STAT6 = (CRC = 3, ResStatus = 0, ORDVELOCITY = 0, PRD = 0, res = 0, ADDR = 111)
        DEV_STAT7 = (CRC = 17, ResStatus = 0, REVID = 3, OPTID = 1, DEVSTATE = 1, FAFECAL = 0, res = 0, ADDR = 225)
      RwReg = (
        DEV_CONTROL3 = (CRC = 40, ResStatus = 0, EXTEN = 0, LPEN = 0, SPIDIAG = 0, reserved = 0, ADDR = 221)
        DEV_CLCRC = (CRC = 55, ResStatus = 0, ECCRC = 0, res = 0, ADDR = 79)
        DEV_CRC = (CRC = 15, ResStatus = 0, RCRC = 97, res = 0, ADDR = 15)
        DEV_CRCCALC = (CRC = 4, ResStatus = 0, CRCCALC = 255, res = 0, ADDR = 217)
        DEV_EE_CTRL1 = (CRC = 24, ResStatus = 0, EECMD = 0, res = 0, ADDR = 227)
        DEV_CRC_CTRL1 = (CRC = 46, ResStatus = 0, CRCCTL = 0, res = 0, ADDR = 122)
        DEV_EE_CTRL4 = (CRC = 32, ResStatus = 0, EEUNLK = 0, reserved = 0, ADDR = 186)
        DEV_UNLK_CTRL1 = (CRC = 2, ResStatus = 0, DEVUNLK = 240, res = 0, ADDR = 100)


For the short testing, I used case 2 with connected IZ*, OE*, and I see that FOSHORT=1 is set when COS or SIN pins are shorted (IZ* shorted), and is cleared when short is removed.

BR,

Markus

Markus,

Thank you for the detailed notes.

• When the IZx pins are disconnected, it is normal for the angle output to continue changing. If you look at AOUT, you will see what looks like a constant velocity output. This will normally cause a fault when FAULTRES is high.
• LPEN and EXTEN cannot be used to enable the tracking loop/start the exciter when the device has detected a fault that turns off the exciter. 
• Most of the fault status registers clear after reading, but this does not clear the fault state from the device. SFAULT reflects the state of the FAULT pin, so it will not be cleared until FAULTRES is toggled.
• A SPI fault will cause the FAULT pin to be triggered, but you should still be able to read angle and velocity data.

Your description of "case 2 - with IZx connected" is still inconsistent. We should see a fault in one of the STAT registers when the fault pin goes high. Can you try timing how long it takes for the fault pin to be asserted after FAULTRES is brought high? You can check this by monitoring the FAULT pin. You can also monitor the AOUT pin and/or the OEx pins to see when the digital tracking loop and exciter output turn off.

Thanks,

-Clancy

LPEN and EXTEN cannot be used to enable the tracking loop/start the exciter when the device has detected a fault that turns off the exciter.

The datasheet PGA411-Q1 says that "The EXTEN and the LPEN bits in the DEV_CONTROL3 register can be used as monitors to determine the state
of the exciter amplifier and the tracking loop. These bits can also manually enable and disable these blocks.", so I assumed that writing these bits would re-enable the exciter. Of course, SFAULT/FAULT is resolved before writing DEV_CONTROL3. Is the information in the datasheet correct, or should a switch to DIAG, resolve fault and switch to NORMAL state be done?

I'll further check the last described problematic state and come back here with the info. Currently I do as follows:

• periodically read STAT5, STAT6, STAT7, CONTROL3, STAT4 (only once ensured via atomic operations, similar to semaphore structure
• in case SFAULT is signalled, read once STAT1, STAT3, CONTROL3
• check/wait for the >=500ms time between FAULTRES signals
• toggle FAULTRES (this should clear SFAULT)
• start again with the reading loop (which again reads SFAULT=1 and reads other registers again, as this should then be a new fault)

So it currently looks like there is immediately another fault, where the exciter cannot be recovered from, but as outlined above, I do not read any (useful) fault info.

Is there a (hidden) mode in the chip that can be used for debugging, which switches to an read-acknowledge instead of clear-on-read?

BR,

Markus

Regarding the case 2:
Monitoring FAULT and FAULTRES lets another FAULT occur 10ms or 40ms after the falling edge of FAULTRES.

Markus,

LPEN and EXTEN can be used to enable and disable the exciter and tracking loop as long as a fault that disables these items is not active.

It sounds like you may have already tried this, but have you tried monitoring the OEx pins on the oscilloscope with a trigger on the FAULT pin?

Have you tried all of this using a second PGA411 EVM?

Are you using the boost of the PGA411 to generate the VEXT voltage? Are the power supply rails stable? 

Thanks,

-Clancy

Yes, I already tried to write to LPEN=1 and EXTEN=1. But the behaviour matches your describtion as the EXTOV fault is/stays active.

There is only the EVM available I have on my table, so I cannot test with another EVM.

Yes, the boost of the PGA411-Q1 is used (via J2 jumper as described in the EVM manual [=default]).
In the case where EXTOV=1, the EXT voltage on the EVM is at 4.8+-0.15V (osci).
In the operating state I measure 12.2V+-0.25V on the EXT test via.
VEXTS is a always a little lower lower than VEXT (~0.15V), but both are stable within the mentioned ranges.

Is the VCCSW output disabled when an EXTOV is detected?