We couldn’t read anything over SPI using the smoke_spi test, and since we had previously had success by swapping out LTC6820s, our first guess was to replace it since it may have been fried by a polarity reversal on BMS carrier (the 12v and ground cable was backwards). However (*foreshadowing*), there weren’t any LTC6820s lying around that were known good, so we took the BMS carrier current sense LTC6820 off and jumped the BMS carrier AFE LTC6820 to the current sense isoSPI lines.
We started checking SPI lines on the oscilloscope because we still couldn’t read anything over SPI.
We’re sending three bytes: 0x11 (stop ADC read data continuous), 0x20 (read registers, starting at register 0), 0x03 (read 1 + 3 registers, so 4 registers total).
MOSI and CLK on BMS carrier side:
It’s a bit fuzzy, but these are clearly the correct bytes.
MOSI and CLK on current sense side:
Unfortunately, the oscilloscope can’t decode these patterns because the isoSPI clock works slightly abnormally, but it’s still a working signal. The bytes are still incorrect though: if you count carefully, the bytes seem to be 0x88, 0x90, 0x01.
However, there still seemed to be three pulses, so we decided to compare MOSI on BMS side and current sense side.
MOSI on both sides, blue is BMS side and purple is current sense side:
The signals do seem to sort of line up.
After a flash of brilliance, Aashmika thought to check if we could just shift the signal by 1 bit. After counting (and some fudging), we realized that if we shift 0x88 0x90 0x01 left by 1 bit, if you discount the initial bit and include an extra high bit at the end, you do in fact get 0x11 0x20 0x03, which is what we were initially sending. The first bit gets ignored because it’s no longer aligned with the clock, and the last bit is high because it’s the end of a byte and MOSI gets pulled high.
From there, we changed what we were sending to be 0x11 << 1, 0x20 << 1, 0x03 << 1, and we got the correct result for the first 4 registers: 0x25, 0x08, 0x80, 0x00. This is the same as what was previously seen for current sense rev 2 validation.
However, this seems to be more than a time constant issue, because there’s a longer delay between SPI bytes than between bits, but shifting left cause all the bits to be correct.
Liam suggested this could be a SPI mode issue, but the pins were correct on the current sense LTC6820. However, we realized that the AFEs use a different SPI mode, so the BMS carrier AFE LTC6820 was configured to take input with SPI mode 3 instead of mode 1, which was what we were sending. So in the end, changed the SPI mode, then re-ran the smoke test, and got the expected response. All’s well that ends well I suppose.
Upon running the smoketest and updating some of its bit math, things work well! we get really pretty precise readings (within 10 mA) with the eload connected directly via current sense to the power supply.
Note that in this picture the vrev mv is 2500, it’s just truncated when it prints in minicom
