Because of the Thanksgiving holiday in the U.S., TI E2E™ design support forum responses may be delayed from November 25 through December 2. Thank you for your patience.

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AFE7071: 4 pin SPI mode, SDO does not enter high Z with SDENB high

Part Number: AFE7071

Hello Ti,

I am running the AFE7071 in 4 pin SPI mode by enabling bits 6 (sif_4pin) and 7 (alarm_or_sdo_ena) in register CONFIG3 (INTERFACE SELECTION).  SDENB is set low when communicating to the AFE7071, in much the same way Chip Select works in SPI.  When the SDENB signal goes high, it appears that the SDO pin 34 does not automatically revert to HighZ mode, rather it remains low.  It appears that the only way to get ALARM_SDO to return to HighZ mode when register readout is done is to clear bit 7 (alarm_or_sdo_ena) in register CONFIG3 (INTERFACE SELECTION) by writing to that register again.  When running in SPI mode, shouldn't the SDO pin return to HighZ when chip select is high?


Thank you

  • JMT:

    I have not investigated this condition specifically, but the datasheet does state that the SDO pin should return to High-Z state once SDEN is re-enabled.

    In the 4-pin configuration, ALARM_SDO is data-out from the AFE7071 during the data transfer cycle(s). At the end of the data transfer, ALARM_SDO outputs low on the final falling edge of SCLK until the rising edge of SDENB, when it enters the high-impedance state.

    If this is not happening, I am not sure of the reason.  Does this condition cause an issue with your system?  Is there something else in the path (i.e. buffer, pull-up/down resistors, etc.) that could impact that standing status of that bit?

    --RJH

  • Hello RJH,

    Thank you for your response.  Yes, I see that the AFE7071 datasheet says that SDO is supposed to enter the high-impedance state when the SDEN goes high.  However, this is not what I am finding to be happening.

    After I run my normal configuration, the AFE7071 register 3 bits: 6 and 7 (sif_4pin and alarm_or_sdo_ena) are both enabled (set to 1).  I wrote a bit of test code to help troubleshoot what is happening.  I enabled the weak pull-up resistor on the MCU MISO pin, so when all devices on the MISO line are in high-impedance mode, the MISO line will be high.  I added some test code following the AFE7071 configuration.  I read register 3, pause for ~100uSec, then write back to register 3 the same thing, except bit 7 (alarm_or_sdo_ena) cleared.  I then monitor the SDO / MISO on an o-scope.

    When I look at the O-Scope capture, the MISO line does not enter high-impedance following the register 3 read when SDEN goes high, as the data sheet indicates it should.  However, as soon as I finish writing the updated register 3 value, with bit 7 alarm_or_sdo_ena cleared, AFE7071 SDO goes to high impedance.  Since the SDO goes to high-impedance as soon as I command it to by writing register 3, I think something must going on with the AFE, where the SDO is not automatically entering High-Impedance and cannot be something else on the SPI bus that is holding the MISO line down.

    When I am done configuring the AFE7071, I need SDO in the high-impedance state in order to access other devices on the same SPI bus.  The ideal solution is for the SDO to automatically revert to High-Impedance as soon as SDEN goes high.  If this cannot happen for some reason, then an acceptable but far from ideal work around solution is to manually set or clear Register 3 bit 7 (alarm_or_sdo_ena).

    Green = CS / SDEN, Blue = MISO, Yellow = MOSI, Magenta = CLK

  • JMT:

    Good detective work on your end.  Agreed, the register should return to High-Z state.  I do not fully understand why this is not happening properly.  It seems like this bit is getting "stuck" and requires a reset with toggling register 3b7.  Unfortunately, I think that your remedy of toggling that bit is the best short term solution.

    --RJH