AnsweredAssumed Answered

Corrupted data samples of ADIS16448 on beaglebone black (am3358)

Question asked by Korbinian on May 27, 2015
Latest reply on May 28, 2015 by NevadaMark

Hi,

 

reading samples of an ADIS16448 on a beaglebone black (BBB) in burst mode via the /dev/iio:device interface I get, from time to time, corrupted data samples. I found out that, apperently, the first byte of the burst stream gets somehow lost, so the whole data blob is shifted by one byte to the left. It seems that the data comes already corrupted from the SPI subsystem (OMAP2_MCSPI). To verify this, I included some debug output in adis16400_buffer.c->adis16400_trigger_handler: right after the call to spi_sync I printed the data if data corruption is detected (byte 24 is zero with 12 channels  enabled, I extended the driver for a DIAGSTAT channel). Further, I printed the next data blob which is not corrupted for comparison.

 

Data error:  00 FF FD FF FE FF F5 00 03 FF FA 05 58 31 5B 68 31 07 30 BC 19 FF 91 00

Next frame: 00 00 FF FF FF FE FF F5 00 04 FF FA 05 57 31 5B 68 31 07 30 BC 19 FF 91

 

The corruption happens very rearly. I found a bug report (http://e2e.ti.com/support/arm/sitara_arm/f/791/p/321533/1158126) with a similar issue but the bug mentioned there is reproducible and occurs only in DMA mode. I get data corruption in DMA as well as in PIO mode so I think the bug report is not relevant for my problem.

 

Has anybody experienced  a similar issue or has an idea how to resolve it? Could this be related to the IMU or is it more likely a problem of the SPI interface on the BBB?

 

Best regards,

Korbinian

Outcomes