SPI for AFE5809EVM Demodulator Registers

Duncan,

Can you confirm that you have followed this procedure from pg 44 of the datasheet?:

 

5. Demodulator register readout follows the following procedures:

– Write '1' to register 0x0[1]; pin SPI_DIG_EN should be '0' while writing. This is the readout enable register for demodulator.

– Write '1' to register 0x0[1], pin SPI_DIG_EN should be '1' while writing. This is the readout enable register for ADC and VCA.

– Set SPI_DIG_EN as '0' and write anything to the register whose stored data needs to be known. Device finds the address of the register and sends its stored data at the SDOUT pin serially.

 

NOTE

After enabling the register 0x0[1] REGISTER_READOUT_ENABLE, data can't be

written to the register (whose data needs to be known) but stored data would come

serially at the SDOUT pin.

– To disable the register readout, first write '0' to register 0x0[1] while SPI_DIG_EN is '1'; then write '0' to

register 0x0[1] while SPI_DIG_EN is '0'.

 

Thanks,

Chuck Smyth

Hi Chuck,

Thanks for replying so quickly.

Yes, I can confirm that we are applying the SEN/SPI_DIG_EN sequence shown in the datasheet (although we are using the Rev "E" datasheet so this sequence is given in section 8.5.1.3.5 on p50 and in section 8.6.2.1.1 on p71). There are no relative timings given for the SEN and SPI_DIG_EN though and so we have tried various delays between SPI_DIG_EN going low and SEN going low, and also when the signals go high again.

As I said before, we can read the demod register contents most of the time (in most of our test code's loops) but sometimes (in some loops) the data bits returned are zero. This says to me that there is no fundamental error in our access method,

Another test I performed since my first post was to re-read the register contents back three times for every write. I can see some return values varying from zero to a reasonable value within the 3 reads. I also see some return values returning the *previous* value I wrote to that register, from which I conclude that both the write and the read are unreliable.

Your further thoughts will be appreciated.

Duncan

Hi Chuck,

Do you have any advice for us on this issue? It's holding up development of our product so we are keen to get it resolved as soon as possible.

Thanks,

Duncan

Hi Duncan,

We have verified a very stable readback using the EVM and GUI.   Here is my sequence

 

1. With SPI_DIG_EN=1, write    0x0[1] REGISTER_READOUT_ENABLE=0

2. With SPI_DIG_EN=1, write    any register, such as reg 0x05 as 0xAAAA

3. With SPI_DIG_EN=1, write    0x0[1] REGISTER_READOUT_ENABLE=1

4. With SPI_DIG_EN=1, write    any register, such as reg 0x05 as any data.

5. See Readback data consistently on the oscilloscope while probing SDOUT at TP12, as well as P14 (SPI signals). Make sure to use the board GND and not DGND of P13, which is USB GND

 

Then,

 

1. With SPI_DIG_EN=0, write    0x0[1] REGISTER_READOUT_ENABLE=0

2. With SPI_DIG_EN=0, write    any register, such as reg 0xC5 as 0xAAAA

3. With SPI_DIG_EN=0, write    0x0[1] REGISTER_READOUT_ENABLE=1

4. With SPI_DIG_EN=0, write    any register, such as reg 0xC5 as any data.

5. See Readback data consistently on the oscilloscope while probing SDOUT at TP12, as well as P14 (SPI signals). Make sure to use the board GND and not DGND of P13, which is USB GND

 

Q1: Which header are you using to provide the SPI signals?  P14 should be ok.  Then remove FB17 to disable the digital isolators.

Q2: Which DEMOD register are you testing this with?

Q3: Are you writing the SPI with an FPGA? 

Q4: Can you test with the EVM GUI first to verify that the device will readback correctly?

Hi Chuck,

pt 5: For the GND connection we are using the GND on P14 which is board GND.

 

Q1: We are using P14, but we’re doing the following instead to disable the optos: Short U16 pins 9 & 10, lift U20 pin 10 & tie to GND (pin 9). This should give the same effect as removing FB17.

Q2: I use (amongst others) register 0xA1 (reg. 0x21 in sub-chip 1), which is a read/write 16-bit MANUAL_FREQ value.

Q3: No, we use an external microprocessor with built-in SPI.

Q4: We started out like this but could not get any register reads to work. Now the board is wired for external SPI so is not easy to go back and test it again.

Our theory now is that spikes on the flying leads between our development CPU board and the AFE5809EVM board are causing occasional glitches in the SPI signals (although the 'scope traces look OK), so we will await our first production hardware before testing AFE5809 SPI again but that it’s good news that you get reliable reads from the demod registers.

 

Thank you for your help so far,

Duncan

 

Hi Duncan,
I know that you said you will wait for the production hardware. Did you have any luck with the EVM? Actually, this week we did see some funny behavior from the DEMOD readback on the EVM. This could be the GUI, but we are looking into it.

Hi Chuck,

We have not tried SPI access to the EVM again since my last email.

The EVM board is now removed from our development board so will not be easy to try again.

Thanks,

Duncan

Hi Chuck,

Just to let you know that our production circuit boards show no problems when accessing any AFE5809 registers.

It looks like the previous difficulties were caused by stray signal on flying leads.

Thanks,
Duncan