Post Go back to editing

ADXL372 EXT_CLOCK at above 307.2kHz seems to cause extra readings.

I have a product with 3 ADXL372 accelerometers.  With a 390kHz EXT_CLOCK and an ODR of 6400Hz, I've got the accelerometer's in synch at the start, but they lose synch from the second FIFO read:

I counted the SPI clock edges and can confirm that each accelerometer received 3080 clock cycles (8(RegAddress) + 3(XYZ) * 16(2BytesPerValue) * 64(NofReadings) = 3080).  Hence I've read exactly the same amount of data from each.  I suppose the loss of synch must actually mean the accelerometers are either adding or losing samples.

The alignment problems remain at ODR = 1600, 3200.  Yeah the data sheet says "thou shalt only use ODR 6400 for clock > 307kHz", but I thought it was worth a try.

Looking at our external clock signal, from the datasheet we can figure the number of clock cycles per sample as:
=> ClockHz / ODR
=> 614400 / 6400 = 96 clocks per sample

So for 64 samples, 64 * 96 = 6144 clocks.  Here's a capture showing the second reading (all INT signals were aligned at the first reading following accelerometer reset):

(Oops - that label "Flash MISO" should say EXT_CLOCK)

The count is showing the number of rising clock edges between the INT signals.  In this case, only accelerometer 1 has correctly fired after 6144 clocks, the other two have fired earlier.  Hence, the other two have EXTRA samples!  And no, having something extra in this case is not a good thing.  It's not like an extra pay cheque.  It's more like an extra tax bill.

Here's another capture, again at the second reading and this time they've all fired early:

There doesn't seem to be any consistency, so the problem may be related to each accelerometer's internal clock running at a slight different speed, even though we're using the EXT_CLOCK.  As evidence, when I set the accelerometers to use their internal clock, they all still get started by us at exactly the same time.  But this is what we see from the very first readings:

Accelerometer 1 has collected 64 samples before the other 2.  It's internal clock is running faster.

1) Our aim is to have all 3 accelerometers in synch.

2) We have other issues with the EXT_CLOCK line as described here:
https://ez.analog.com/mems/f/q-a/116540/adxl372-ext_clock-spurious-samples

3) We know we can't use EXT_SYNCH because it will miss samples.  Are there a set of requirements for using EXT_CLOCK so it will be 100% reliable?

Thanks!
Richard.



tagged
[edited by: JValeriani at 8:30 PM (GMT 0) on 10 Oct 2019]
Parents
  • I've had the opportunity to test some more of our boards and have stumbled across an interesting coincidence.  It seems a board we have hand soldered is giving this synchronisation problem, but another board that has been reflow soldered does not (it does, but far far more infrequently).  The schematic is identical and tracking is pretty much too, but the faulty board is FR4 whilst the working one is flex.

    I admit this is an unreliable assessment as I've only been able to test a few boards but seeing as most MEMS application notes say you shouldn't place parts under strain or route tracks under them, I wanted to ask if the problem behaviour I've outlined in this ticket is possibly influenced by how the accelerometers have been soldered?

Reply
  • I've had the opportunity to test some more of our boards and have stumbled across an interesting coincidence.  It seems a board we have hand soldered is giving this synchronisation problem, but another board that has been reflow soldered does not (it does, but far far more infrequently).  The schematic is identical and tracking is pretty much too, but the faulty board is FR4 whilst the working one is flex.

    I admit this is an unreliable assessment as I've only been able to test a few boards but seeing as most MEMS application notes say you shouldn't place parts under strain or route tracks under them, I wanted to ask if the problem behaviour I've outlined in this ticket is possibly influenced by how the accelerometers have been soldered?

Children
  • Thanks for your feedback. Currently our product engineering team is revisiting this external clock/missing sample issue on board as well as ASIC level to see if it's reproducible, will update with you once certain workaround is verified to work. 

  • Just a quick follow up, I assume you are using the FIFO watermark interrupt(based on the FIFO sample size) to triggered the FIFO read. Right now it seems you FIFO Sample is set to 64 samples/axis * 3 axes = 192 samples, can you set the FIFO Sample to 510 and give it another try? We've verified this setup on the bench. Please let me know if the missing sample issue still happens or not.

  • I actually set the FIFO watermark to 68, but only read 64, thus leaving 4 samples behind (or maybe more if I've been slow).  We quite like these numbers because it's good for both power saving (our CPU can deep sleep for a while) and responsiveness (we don't wait too long for samples).

    Does this sound ok?

  • On the application level, you are supposed to set any number you want in the FIFO Sample, and trigger interrupts using watermark. We've reproduced the missing sample issue on the bench and are working on a system level workaround. However we haven't seen any sample is missed when FIFO size is set to full, so I'm wondering if you can try this and see if the interrupts can be aligned if no sample is lost on any of your three sensors and then go from there. If this is not the root cause we may have to look into other things. 

  • Thank you for your answer and most importantly, for verifying the behaviour I've reported.  This confirmation has motivated our decision to switch to the internal clock as I mention in my other thread.

    So we might as well move our discussion to the https://ez.analog.com/mems/f/q-a/116540/adxl372-ext_clock-spurious-samples thread --- at the end of the day our problems with the ADXL372 all seem to be related to using an external clock and the various errors this induces in the chip.