Anybody else seen spikes in ADXL345 data? [solved: ADXL good, my bad] - Page 1
Forum section: electronics / general

author: voltsandjolts
author_rank: Unknown
timestamp: August 28, 2020, 11:21:24 am
content: With the sensor at rest, I see sensor noise of 10mg.However, I also see large intermittent spikes, on average about one an hour, just one sample and they are all the same value 0x0500.I have tried various bandwidth settings of 50Hz,100Hz,200Hz. FIFO in steam mode.Reading out data every 2ms or 10ms (tried both) using DMA on PIC24.At the moment I am convinced this is the sensor.If I mask out 0x0500 values, the spikes go away - maybe that would work on just this one chip ? :-)Code:if(acc==0x0500) {acc=last_acc_value;}else {last_acc_value=acc;}

author: tszaboo
author_rank: Super Contributor
timestamp: August 28, 2020, 11:29:55 am
content: I2C or SPI?I would set an MSO or logic analyzer on those lines, and see if they are actually there.When I had strange communication from SPI devices, they were most of the time the clock polarity and phase settings.

author: voltsandjolts
author_rank: Unknown
timestamp: August 28, 2020, 11:44:01 am
content: Quote from: NANDBlog on August 28, 2020, 11:29:55 amI am using SPI. (**)Yes, good point to double check SPI clocking scheme.SPI analyzer set to detect int16 data greater than a threshold would be useful, maybe I need to build something simple for that. After ADXL initialisation, it's only reading out one axis anyway, so quite simple to watch.(**) Hah, that's another debug story. On a previous project there was a SPI FLASH on the same bus as the ADXL. BUT the ADXL can be I2C or SPI, on the same pins. At some FLASH memory patterns the ADXL would suddenly decide it was connected to I2C bus, start transmitting and cause weird FLASH memory corruption. That was fun. I should have read the ADXL datasheet better and implemented the OR gate on CS as they suggested. But I am not a fan of SPI/I2C on shared pins, auto-decision feature.

author: tszaboo
author_rank: Super Contributor
timestamp: August 28, 2020, 01:38:52 pm
content: Well, if you have a MSOX3000 series MSO, you could set up triggers like that.https://www.manualslib.com/manual/1477293/Keysight-Dsox3012t.html?page=449#manualOf course, this becomes complicated if you are transferring 10 bytes, and you only want to trigger on the first. In that case you want a dedicated logic analyzer. Or have a Saleaeaaee USB streaming (or similar) and capture everything.In any case, we are using a ADXL accelerometer on one of our devices, I ask the firmware guys on Monday if they saw any strange data like that. Today I'm working from home.Quote from: voltsandjolts on August 28, 2020, 11:44:01 amThat is so typical with these MEMS sensors. It is super annoying. I started using them only in I2C mode, because SPI is just asking for trouble if you share the bus. I cant believe they didn't hear this feedback.

author: voltsandjolts
author_rank: Unknown
timestamp: August 28, 2020, 05:36:28 pm
content: Great suggestion.MSOX3024 setup to trigger on 0xX1XX and after 20 minutes (at 100 SPI transactions per second) it captured the problem perfectly.Good transaction and bad transaction shown in scope captures.Seems that my DMA transmit is very occasionally forgetting to send the SPI command!Weird!Not sure what command FF means to the ADXL but it seems to responds with 0xE500 which I interpret as 13bit twos complement, becoming 0x0500 (the bad data value I was seeing).

author: KT88
author_rank: Frequent Contributor
timestamp: August 28, 2020, 06:02:06 pm
content: I have seen an ADXL372 recently with weired behaviour. It turned out that a slotted ground plane screwed up the SPI communication. The traces were only a few centimeters long. You may check / post the layout...

author: voltsandjolts
author_rank: Unknown
timestamp: August 29, 2020, 08:55:06 am
content: This is a 4-layer board with full ground plane and the ADXL is close to the MCU, less than 10mm track lengths.I am confident this isn't a PCB layout issue.

author: voltsandjolts
author_rank: Unknown
timestamp: August 29, 2020, 10:50:31 am
content: OK, got it.The ADXL has I2C and SPI on the same pins, with an auto-decision feature to decide which it will use (Yuk, gimmie a seperate pin to tie high/low FFS).The datasheet recommends using an OR gate to keep ADXL SDI high when CS is high.Instead, I opted to use the port pin to ensure MOSI stays high, set high manually.But that SPI port is on the alternate port pin mapping, so to swap MOSI from SPI to PORT pin I had to access OSCCON to change pin mapping.I used __builtin_write_OSCCONL(...) which requires that interrupts are disabled before calling (who knew!).I wasn't doing that and so (very) intermittantly the output pin was not getting switched to SPI function.https://www.microchip.com/forums/m544753.aspx