SPI MISO data bus empty on logic Analyser

[vw_dev]

Hello everyone,

I am working with the SDK v17.1.0 with the DK nRF52832. I want te retrieve data from a battery cell monitor which uses the LTC6804 from Analog Device. 

I am communicating with it through SPI and sending it the trams of commands necessay to read the voltage of the cells. Through a logic Analyser, I see that I am sending the correct frames on the MOSI bus, the clock is working fine and the Channel Select aswell.

The only thing that is always empty is the MISO bus which means that I can't retrieve the data from the LTC6804. I have tried everything that was described in the devzone (Correct Pins, changing SPI mode, pull-up resistors, changing the size of my rx buffer) but nothing worked. 

Do you have any ideas?

Thank you!

The frames I am sending to read the voltage:

My SPI configuration

The logic analyser results:

 

[hmolesworth]

I think MISO should be high - regardless of whether the PEC is calculated correctly - when a tx frame from the host nRF52 is started; since it is shown as low on the logic analyser this implies there is no pull-up fitted (pedantic: or no pin connection or incorrect nRF52 pin config or pin short to ground):

"Connecting ISOMD to V– configures serial Port A for 4-wire SPI. The SDO pin is an open drain output which requires a pull-up resistor tied to the appropriate supply voltage"

[vw_dev]

Thank for the answer!

I added in my setup a pull-up resistor powered by the VDD of the DK, on every SPI buses, and I configured in the sdk_config.h :

NRF_SPI_DRV_MISO_PULLUP_CFG 3

Which configure the MISO GPIO pin into pull-up.  

Now it seems that the data in the MISO bus is the same as the MOSI's as shown in the picture. But no traces of the response... Can you help me with that?

Thank you

 

[Jared]

Hi,

I am communicating with it through SPI and sending it the trams of commands necessay to read the voltage of the cells. Through a logic Analyser, I see that I am sending the correct frames on the MOSI bus, the clock is working fine and the Channel Select aswell.

Usually, this would indicate that the issue relies with the slave. If the output from the nRF really is correct then the slave should respond as described in the datasheet, if it doesn't then maybe the slave isn't configured correctly according to its datasheet?

vw_dev said:

Now it seems that the data in the MISO bus is the same as the MOSI's as shown in the picture. But no traces of the response... Can you help me with that?

Thank you

Given the datasheet of the LTC6804-2 a quick read, I saw that the device has the option of daisy chaining. Which would explain why it's replicating the data that is sent on MOSI onto MISO. Most likely the slave is configured to be SPI master for daisy chaining, I suggest that you doublecheck the datasheet and verify if it's configured correct or not. Also the internal pull-up on the nRF is 13k.

regards

Jared 

[hmolesworth]

The picture shows a different waveform on MISO to that on MOSI, which is to be expected and might even be correct. The decode above MISO on the picture seems to indicate the logic analyser has been set to decode MOSI on both traces instead of MISO on the 2nd trace

[Jared]

fair point, vw_dev could you double check this?

[vw_dev]

Hello, 

Thank you for your answer. 

The slave is configured so that when it receive commands frames, it would respond automatically. I only changed the physical jumpers to disable isoSPI communication and enable SPI communication. 

On the slave board, the uC used is the LTC6804-1, which is indeed daisy-chainable. I know that the slave is also configured so that it transmits the data to a external uC as the nRF. I am only using one slave, so I assumed that the slave would respond only after receiving command frames. 

[vw_dev]

What I find strange is that on a normal SPI communication, the response on the MISO bus should be after receiving the command frames, which is not the case here. 

The logic analyser is only displaying what data go through the bus, right? So I don't know if the issue is starting from here