Post Go back to editing

LTC3300 SPI mode not consistent

Hello all,

I have been using LTC3300-1 successfully for a couple of year.  The LTC3300 is on a separate PCB.  It is driven (SPI) by the MCU PCB with an ATmega2560 MCU.  On the MCU PCB there is also a LTC6810 cell monitor.  Considering that I could no longer buy LTC6810, I redesigned the MCU PCB using an ESP32-S2 MCU and a different method to monitor cells. 

The balance PCB has not changed, but SPI communication does not work althought the commands sent by the MCU seem correct!

I have the impression that the SPI mode used by the LTC3300 when a sending data (read command) is not the same as the documented mode..

My understanding is that the LTC3300 SPI mode = 3: clock idle high, bits shifted on falling edge and data sampled on rising edge

For my tests I send a write command (A9) with command bytes 0C 06 (charge cell 3), then I do a read back (AA) to read 2 bytes.  I use very slow rate (50 kb/s) to be sure there are no influence of possible line delays. (exactly the same observations at 500 kb/s).   note: all data is shown in HEX.

1) scope set to read data on rising edge:

  • the write command is properly read by the scope as A9 0C 06
  • the read command is properly read as AA
  • the bytes returned by the LTC3300 are read as 18 OC and this is also what the MCU reads (this is 0C 0D shifted one bit to the left - meaning that it misses the first bit)

2) now same thing with the scope set to read on the falling edge:

  • the commands sent by the MCU are obviously garbled
  • the bytes returned by the LTC3300 are properly read as 0C 06

3) looking at it more closely:

This trace is a zoom on the end of the read command and the first bits sent by the LTC3300

This confirms that the write command has its bits shifted on the falling edge (purple MOSI)

But the the bits sent by the LTC3300 shift on the rising edge of the clock (dark blue MISO).  An even closer look shows that the bit is shifted 140 ns after the rising edge of the clock 

I must be doing something wrong somewhere!  Would anyone be able to put me on the right track to get that sorted out.

Thank you



added details on what has changed since it was working
[edited by: pjeanmaire@taoperf.com at 5:08 AM (GMT -4) on 7 Apr 2022]
  • I did additional tests by inserting a delay between CS down and start of the clock, adding a dummy clock beat between the read command and the start of reading data sent by the LTC3300, and at different clock rate.  Always the same result:  the data bits out of the LTC3300 are shifted 140ns after the rising edge of the clock (when it should be within 250ns after the falling edge). 

    Can anyone at Analog Device help me find the cause for this problem?

  • More details:

    I did the same tests using the old MCU PCB (ATmega2560)... and found that the traces are exactly the same - meaning that when the LTC3300 sends data bits, they are shifted on the rising edge of the clock - so it is consistent and the issue is not new.

    I guess I was lucky that the old MCU could read the data sent by the LTC3300 - although it was unstable and I had to read in a loop until I could get the correct CRC (at the time I thought it had to do with the PCB design and I did not worry considering I could get a good reading with 10 loops). 

    I am not that lucky now with the ESP32-s2 and readings are always wrong!! 

  • Hello,

    I was just looking at this. What I can see on the scope shots it appears that the LTC3300 might be sampling on the rising edge and shifting out on the falling edge. I am thinking that it might not be SPI mode 3. I would expect mode 2. Is it possible to see if changing modes fixes the problem?

  • Hi Marty,

    Thanks for your suggestion.  Here are the traces using SPI mode 2:

    It shows that the LTC3300 does not register the write command as the read back returns 0's.

    That confirms LTC3300 expects SPI mode 3 when writing to it, but it uses SPI mode 2 when sending data (reading from it).

    I think Analog Device is confused about SPI mode.  The descriptions of the modes on the AD document you attach are wrong (CPOL and CPHA are right, but the descriptions are swapped between mode 2 and mode 3).

     Here are a few way it is described by others:

    "With inverted clock polarity (i.e., the clock is at logic high when slave select transitions to logic low):

    • Mode 2: Clock phase is configured such that data is sampled on the falling edge of the clock pulse and shifted out on the rising edge of the clock pulse.
    • Mode 3: Clock phase is configured such that data is sampled on the rising edge of the clock pulse and shifted out on the falling edge of the clock pulse." 

    or:

    and:

    They all say the same thing and it is different from what Analog Device says in this article published on its official website:  https://www.analog.com/en/analog-dialogue/articles/introduction-to-spi-interface.html - this is worrying!

    Based on these definitions and the LTC3300 datasheet, the LTC3300 uses SPI mode 3 (CPOL=1, CPHA=1):

    Please tell me that I am wrong and tell me what needs to be done for the LTC3300 to behave the way it is detailed on the datasheet.

    Let me know if you need more tests and measures.

  • This issue has still not been addressed properly or resolved.

    I have been in contact with the Australian Field Application Engineer who confirms that there is a discrepancy between what is observed and the datasheet.  He was going to refer that matter to ADI experts but still no reply after many months and no more answers from the FAE!

    As ADI has been unresponsive and all our measures show that the LTC3300 does not comply with the datasheet, we are now thinking about redesgning our balancing PCB without the LTC3300 - which we would prefer not to do! 

    Can someone from ADI get back to me so that we can get that issue sorted out.  
    PLEASE HELP