SPI question (0xff in DR)

[st.2]

Posted on April 22, 2015 at 04:58

Hello everyone, 

I checked the data sheet but couldn't find an answer to the following question:  What should happen if master initiates transmission but slave is detached or powered down?   In my tests once master sends the first byte, both TXE and RXNE are set high as if there is input data ready. I also checked DR and it contains 0xFF, so the first and all subsequent reads all return FF's. This is a valid data that could be returned by slave so there is no way to tell that slave is detached.  I am pretty sure the first time I tried I got all zeroes in DR in this case, now they are all FF's.  I checked the GPIO configuration and the MISO pin is configured as input floating so it happens to always be high. If I pull it down, I got all zeroes as before.  So my quick fix was to configure the MISO pin as input pulled down, but this contradicts  recommendations in the data sheet.  And of course it is a simple coincidence that in my case zeros indicate an error.  I must be missing something. If MISO is floating, then its state is unpredictable so there must be some other way to tell that slave is not communicating. I would think that would the RXNE flag, so I don't understand why it is set if there is no input.   This is stm32f100c6 (LD VL) Thanks #stm32f100x

[Tesla DeLorean]

Posted on April 22, 2015 at 06:44

But the bus is symmetrical, you have one clock, as the clock shifts the bits out, it shifts an equal number of bits back in. It neither knows nor cares if the slave is responding or not, it's sampling the state on the pin at a specific clock edge.

The typical way to detect the presence, or lack of, a slave device is to read an ID register, or multiple ID bytes. ie the make/model of a serial SPI flash device Or that you can read/write into specific registers, and the content returns as expected vs junk.

[st.2]

Posted on April 22, 2015 at 17:36

Yes, that's what I thought but I am confused about the meaning of the RXNE flag then.   Specifically, in the full duplex master mode, if write succeeded (and why wouldn't it) that means the DR register has been updated with an incoming byte and of course RXNE will be set.    So basically, in the full duplex master mode all writes/reads will ''succeed'' by definition? Perhaps RXNE is useful in other modes, maybe as slave?  

[Tesla DeLorean]

Posted on April 22, 2015 at 17:50

It depends what your definition of ''succeeds'' is. I think you need to review some texts on SPI, and the functional block diagram in the reference manual. The slave either responds with a bit or it doesn't, the master doesn't care, and isn't waiting around for something to show up. The master has no way to gauge ''failure'' of the slave to respond as expected/desired.

TXE indicates the output holding buffer is empty, it asserts as the holding buffer is moved to the shift register, and the first bit hits the wire.RXNE indicates the input buffer is full, it asserts as the shift register content is moved to the holding register, and occurs after the last bit has been pulled from the wire.In a write only sense, the RXNE can be considered as a DONE or TRANSFER COMPLETE indicator.Also be cognizant that the value you write into DR goes to a different buffer than the one that holds the value you read back. It is not a memory cell. Reading DR in the debugger will also clear status register bits.

[st.2]

Posted on April 22, 2015 at 22:29

Thanks, I think I got it.  But I still think that it is probably a good idea to avoid a floating MISO. For example, if the slave is a temp sensor, say lm72, all ff's is a valid temperature and it is not practical to check the device ID on every call as the sensor would need to be shut down then powered up again. I guess that could be done every once in a while to make sure the sensor is still there.  But it is easier to pull MISO low, which will result in all zeros, an invalid result for this particular sensor.  Just making sure this approach wouldn't cause any other issues. 

[Tesla DeLorean]

Posted on April 23, 2015 at 03:55

Yes, pulling low would help you. Do you expect the sensor to disappear at some point, or is it physically mounted?

If you expect it to disappear or fail, you should probably do a check periodically, and monitor for a odd rate of change.

[st.2]

Posted on April 23, 2015 at 04:30

Could potentially be implemented as a remote detachable/hot swappable sensor or a group of sensors measuring various parameters, so yes could be poor contact or physical damage/vibration etc.  The same parameter (such as temp) could be measured at different points to calculate an aggregate state/gradients etc, so if one sensor is out that may skew the results, so yes need to able to detect an invalid data with minimum delay and discard it. Yes planning to implement various moving averages, rates of change etc. since it is needed anyway.