AnsweredAssumed Answered

ADIS16480 Register Writes to PAGE_ID 0x03 problems

Question asked by Tsudo on Dec 16, 2013
Latest reply on Dec 17, 2013 by NevadaMark

Hi,

 

I have recently connected an ADIS16480 to an MSP430 microcontroller to test some basic code (ultimate application is a bore-hole logging tool).

 

I have run into a very strange problem when reading/writing to the registers of page 0x03 (control page).

 

If I write a simple test loop like this:

 

uint16_t reg = 0;

uint16_t i = 0;

for(i=0; i< 2048; ++i)

{

          WriteIMUReg(CALB_HARD_IRON_X, i);

          reg = ReadIMUReg(CALB_HARD_IRON_X);

 

 

          if(reg != i)

                    fail++;

          else

                    success++;

}

return success;

 

That writes to and reads back from that register 2048 times, counting the times it's successfully read back correctly. (the WriteIMUReg checks the current PAGE_ID as last written and issues the appropriate PAGE_ID write command if the page needs to be changed).

 

I get 2048/2048 successes. 

 

I can repeat this test with any register from page 0x02 or the Filter tap pages without a problem.

 

However, if I try and do this with DEC_RATE or DECLN_ANGL or any other Page 0x03 register:

 

DECLN_ANGL:

~44/2048  (10 Hz  - DEC_RATE(245)) 

~75/2048 (2.4 kHz  - DEC_RATE(0))

 

DEC_RATE:

~2045/2048

 

It varies from execution to execution how many are (or are not) successful.

 

I've tried reducing the SPI clock from 8 MHz to 250 kHz with maybe a small improvement (but not 100% reliable).  I've tried only setting the registers immediately after a rising edge on DATA_READY.  I've tried putting bigger delays in between the SPI writes (I've checked all the timings and confirmed the correct SPI sequences on a scope) but nothing seems to help.

 

I've gotten around the problem (for now) by using loops to readback the registers I'm trying to write and not giving up until they've been read back successfully.  Once I get the thing initialized, it runs beautifully (all the sensor/orientation data comes out OK).

 

I've either got a defective ADIS16480, or I'm doing something wrong somehow (more likely )... But the fact that it works so well for the other pages of data has me mystified what it could be. 

 

I was hoping someone might know something about the ADIS16480 that would help me diagnose what I've got wrong... Is there something about the timing/operating requirements of page 0x03 registers that might be causing this behaviour?

 

Does setting Page_id 0x03 cause the device to become more sensitive to electrical noise?  Does it suffer from SCLK jitter on page 3 ? (it's a digital oscillator based SCLK, so it's not as stable as a crystal)...

 

At this stage my options are trying it on a different architecture (ultimately it'll be connected to a xilinx fpga), buying a second unit (expensive ) or redoing all my electronics!

 

Any suggestions to try would be appreciated - I'm at my wit's end

 

--Kyle

Outcomes