LIS3DSH SPI接口不能读取奇数地址的寄存器

在过去的几天里，我一直在撞墙，试图弄清楚为什么我不能通过LIS3DSH SPI接口和nRF52832读取奇数地址的寄存器。对偶数地址的字节访问工作正常，但对奇数地址的字节访问总是将寄存器的值返回到低一个位置的偶数地址。 16位访问仅在地址为偶数时有效。似乎寄存器地址的LSB始终由LIS3DSH读取为零。
通过I2C总线进行通信工作正常 - 字节，字，偶数和奇数对齐都可以。
所以，在我看来，LIS3DSH在SPI接口中有一个错误。我最好的猜测是，SCL的上升沿在内部没有正确锁存地址的最后一位，并且必须保持静态，直到SCL的下一个下降沿（此时LIS3DSH开始驱动数据总线）。
这是我的证明：
下面显示的是逻辑分析仪捕获，显示WHO_AM_I寄存器（地址0x0F）的单字节读取。底部4条迹线是前四条的延迟（扩展）版本。在这里，我在传输的“地址”阶段的第8个时钟的上升沿之后将MOSI（SDI）驱动为零。保持时间显示为约460nsec。您可以看到在接下来的8个时钟期间返回的数据（MISO）是0x00（对应于寄存器0x0E，INFO2）。
在第二次捕获中，我保持地址的最后一位，直到同一时钟的下降沿。此处，返回的数据对于WHO_AM_I（0x3F）是正确的。
数据表显示相对于SCL的上升沿，保持时间仅为15纳秒。看起来你必须保持地址的第8位（只有第8位）直到SCL的边沿。
那么，这是芯片中的一个错误吗？我在勘误表中没有看到任何提及。
如果地址的最后一位通过数据传输保持静态，则这不是问题。在我的情况下，我现在正在敲击I / O端口，所以我只是将MOSI（SDI）引脚置于其最后状态。
不幸的是，一些微控制器的内置SPI接口（如nRF52832）在读操作期间地址的最后一位输出后立即将MOSI线驱动为低电平。这意味着您不能对奇数地址的寄存器进行单独的字节读取。解决方法是进行字对齐的16位读取并选择正确的字节。幸运的是，LIS3DSH中的16位X，Y和Z数据值是字对齐的，而像nRF52832这样的芯片的16位SPI读取工作正常。



以下为原文




I've been beating my head against the wall for the last couple of days trying to figure out why I cannot read registers at odd addresses through the LIS3DSH SPI interface with the nRF52832.  Byte accesses to even addresses work fine, but byte accesses to odd addresses always return the value of the register at the even address one location lower.  16-bit accesses only work when the address is even.  It seems like the LSB of the register address is always read by the LIS3DSH as a zero.
Communicating via the I2C bus works fine - bytes, words, even and odd alignment are all OK.
So, it looks to me like the LIS3DSH has a bug in the SPI interface.  My best guess is that the last bit of the address is not correctly latched internally by the rising edge of SCL, and must be held static until the next falling edge of SCL (at which time the LIS3DSH starts to drive the data bus).
Here's my proof:
Shown below is a logic analyzer capture with showing a single byte read of the WHO_AM_I register (address 0x0F).   The bottom 4 traces are a delayed (expanded) version of the top four. Here, I drive MOSI (SDI) to zero after the rising edge of the 8th clock in the ''address'' phase of the transfer.  The hold time is shown to be about 460nsec.  You can see that the data (MISO) returned during the next 8 clocks is 0x00 (corresponding to register 0x0E, INFO2).
In the second capture, I hold the last bit of the address until the falling edge of that same clock.  Here, the data returned is correct for WHO_AM_I (0x3F).
The data sheet says the hold time is only 15 nsec, relative to the rising edge of SCL.  It looks like you have to hold the 8th bit of the address (and only the 8th bit) until the  edge of SCL.
So, is this a bug in the chip?  I didn't see any mention of this in the errata sheet.
This is not a problem if the last bit of the address is held static through the data transfer.  In my case, I'm now bit-banging the I/O ports, so I merely leave the MOSI (SDI) pin in its last state.
Unfortunately the built-in SPI interface of some micro's (like the nRF52832) drive the MOSI line low immediately after the last bit of the address is clocked out during read operations. This means you can't do individual byte reads of registers at odd addresses.  The work-around would be to do a word-aligned 16-bit read and select the proper byte. Fortunately the 16-bit X, Y, and Z data values in the LIS3DSH are word aligned and 16-bit SPI reads with chips like the nRF52832 work fine.