I am trying to interface an ADXL372 with Freedom board. I am able to talk to the ADXL372 i.e. able to read Device ID, Part ID etc.Most of the times it works fine. But sometimes, i see that the MISO is held high by certain commands e.g. when i send 0x03 i get the expected result, but after that MISO stays high till any other command is sent. The MISO will stay even after deselecting the chip (CS = high).
I don't have any other device connected to SPI.
Has anybody faced this issue?
Thanks for your question. It seems a weird issue to me.
When you said you sent 0x03, do you mean you talked to register 0x03 with some data? or did you talk to some register with the data sent as 0x03?
Also, when the MISO is idle high as you mentioned, if you do a read from the Device ID register(0x00), is it outputting 0xFF or it's outputting the correct value as 0xAD?
Do you have some waveforms available so we can have a quick check on what's happening before and after you "sent 0x03"? Thanks.
Thanks for the quick reply.
I configured the MISO pin on the controller to pull down, after that the pin comes down. But still, i see an unnecessary spike some times. Please refer the attached waveform.
In the attached waveform, you can see after the CS and clock have been disabled then the MISO is going high, which seems weird. I have also attached a zoomed pic of the trailing edge of the CS, where the issue lies.
When i am reading X/Y/Z registers, i am getting a lot of FF values in the MSB, while the chip is at rest. I think they are also related to this issue.
Thanks for the screen capture.
Based on your capture, it seems you set both of your SPI polarity and phase to zero which is OK. However, your SPI timing doesn't look correct. You did a SPI write of 0x13 at your Freedom board in order to read the register 0x03 of the slave device. But if you count how many rising edges on your SPI clock line to sample 2 bytes of data, you'll only find 8+7 rising edges and you miss the last one. You pull the CS high while MISO is still outputting its last bit which could lead to some weird stage as you saw. I would suggest you may take a look at your SPI driver code first and see if there's any issue there. You may also compare this capture with those successful SPI timing diagrams you had early on.
Hope this helps.
Looks like, there was an issue in capturing the data. There was actually another rising edge in the middle.
Please have a look at the attached screen shot. You will find 8+8 rising edges.
Even now, sometimes ADXL372 is transmitting data (sometimes) ever after the CLK and CS are disabled.
Ideally a slave should turn the tri-state MISO to high impedance as soon as CS is disabled, which does not seem to be happening with this ADXL372 evaluation board that I am using.
Also, can you please confirm if i really need to configure a pull down (and why?) on the MISO on the controller side to help ADXL372 bring it to 0, otherwise the MISO sometimes gets stuck at 2.8V. Vs/VddIO of the evaluation board are connected to 3.3V.
Thanks for the update on the capture. You're correct that once your CS is pulled back high, your slave MISO will turn into high impedance state.(High impedance doesn't mean the voltage level should be 0V or you need to pull it down to 0V). In addition, there's no bus keeper in this part to hold the MISO line at its last value, so you should not see the voltage level of MISO drop to the ground immediately as you expected.
Regarding your reading issue of your data registers(you said you got a lot of 0xFF), have you tried combing your high byte and low byte together, converting it and checking if the output is within the noise range when your sensor is at rest? Since the output range of the sensor is ±200g, you could get some negative value formatted as twos complement.
Hope this helps.