Howdy,
My team and I are planning to use the Sen 15335 IMU board in one of our projects, but there appears to be an issue reading from some of the data registers. We are using the SPI communication and have configured the user control register to turn off I2C. We are able to read and write data to the device, however the reading of certain registers will cause the device to stop responding. We have probed the signal lines to verify that the master was controlling the CS, SCLK, and MOSI lines correctly, but there is not a response from the MISO line after the device seems to get hung.
We have observed this at multiple signal frequencies and signal levels. Each time the device performs as expected until a problem register is polled and the device no longer responds to any input until the power is cycled. Sometimes the problem registers can be read once or twice before the device is hung.
The IMU datasheet identifies registers to write to when the I2C lines are hung, but there is no mention that we could find of resolving this sort of SPI issue.
Below are captures of the SPI signals. From the top down they are CS (yellow), SCLK (blue), MOSI (purple), MISO(green). In the first image the slave device can be seen responding to the reading of the WHO_AM_I register.
In the second image we observe a successful read operation of the ACCEL_XOUT_H register (a problem register).
Then in the third image, where the ACCEL_XOUT_H register is polled a second time but there is no response from the device.
Finally the fourth image shows that the Who_am_I register read operation also fails after the device has been hung.
We have been unable to find anything in the datasheets that would explain or refer to this type of issue, is it possible that there is a component issue on the board itself?
For some reason I am unable to attach the relevant images to my post/reply. Essentially in the first two images we can see activity on all of the data lines, and in the last two images the CS, SCLK, and MOSI lines are all correct as the first two, however the MISO line is held constantly high with no bits being communicated.
Hi jstockton - that is an interesting issue you are describing. That should, for example, cause issues in the [first example because the```
getAGMT
The Sen15335 is the only device we are currently working with and it is the only one we have at the moment so we are unable to run a comparison. 50% of the sensor data registers are unable to be read consistently without causing the device to become unresponsive (MISO line no longer drops low after CS is activated) and requiring a power cycle. The REG_BANK_SEL register is also problematic, both reading from and writing to this register can cause the device to hang. Read/writing from the FIFO_EN_2 register once caused the device to hang but this has not been replicated again.
Is it likely that this is a hardware issue with the specific chip/board? From the supporting documents I cannot find a way to describe why the device is capable of R/W SPI communications for some registers but hangs during others, it seems that if there were an issue with the protocol or wiring then it would be a more persistent or random issue as opposed to being related to the function of specific registers.
We have been unable to run effective tests on register banks 1-3 as the selection register causes the device to hang more than half of the time it is read/written.
From your description of the issue I do suspect the particular chip that you have - though it is a very unusual kind of issue to see in silicon. We sell 60 or more of these devices per week and yours is the first report of such an issue that we have encountered.
Have you written your own software to interface the chip or are you using our provided code?
We have been using a LabView program alongside a NI CompactRIO as the master controller. We have determined that the error is due to the wiring between the power supply, cRIO, and the Sen15335 board. After shortening the power and signal lines and rerouting the cRIO signal ground to travel alongside the signal lines the device is now functioning correctly. Best guess is either a buildup of current in the Sen15335 due to non-ideal ground connections or general interference with regards to noise from the previous signal line spaghetti. When writing out the binary addresses for the sensor registers, we noticed that the problem addresses required the MOSI line to toggle back and forth considerably more compared to those that were readable without issue. The increased toggling of the line would have made these addresses more susceptible to noise interference.
Thank you for your help and time.