I'm posting this a new question but it's really a continuation of the question I posted over 3 years ago under the heading AD7763 Filter Download Question (I wasn't sure if the old question would still be monitored).
In summary we cannot get the filter download to work correctly in our configuration. We have proven that the coefficients are effectively shifted by one word, i.e. the first coefficient loaded is interpreted by the device as the second and the final coefficient is interpreted as the checksum; the device is always interpreting the first coefficient as zero.
The following describes the configuration:
- We have 4 AD7763s running together using MCLK = 25.6 MHz and with SCR = 0 and CDIV = 0 so that ICLK = MCLK/2 = 12.8 MHz and SCO = 12.8 MHz.
- We have the decimation set to x16 so our output sample rate is 100 kHz.
- Our SYNC pulse is 8 x MCLK periods wide and both edges are synchronous with the rising edge of MCLK.
Using the default built-in filter everything works perfectly, we have no problems with synchronisation of the 4 devices. We have also very carefully checked the timing and we are sure that the setup and hold times are met for the register writing and the coefficient writing. We know that the register writes work for all 4 devices because when writing various combinations of the register 1 settings we always get the expected results.
If we try to write the example filter to the device (all 4 devices at the same time by addressing with the SPI_ALL bit set), the DL_OK or FILTER_OK bits are both 0. However, we have discovered that if we replace the last coefficient by 0xDC9 (this being the correct checksum for the preceding 11 coefficients) the DL_OK bit is then 1. Writing different values for the 13th value (i.e. the one that should be the checksum) has no effect on the status. Writing any value other than 0xdc9 for the 12th coefficient results in the DL_OK bit being 0.
The implication is that we are failing to write the first coefficient and that it is defaulting to zero. We have not seen the FILTER_OK bit set at all.
As a further check to prove this theory I have set the first coefficient to 0x03FFFFFF and all the others to zero and I can see by examining the output data that the filter has a gain of 1 as expected. If I then change this to the first 11 coefficients to be zero and the last one to be 0x03FFFFFF I then get a gain of zero, i.e. the last coefficient is ignored and is actually interpreted by the device as the checksum. I have also tried this using a full length filter (48 coefficients) with the same result.
We have very carefully checked the clocking of the register 1 word and the coefficients and we are sure that there is not a spurious frame sync prior to writing the first coefficient (which may have explained the extra word of zero).
We have also tried various delays between writing the register 1 word and the first coefficient and between the coefficients. None of these has had an effect.
So, do you have any idea what, if anything we are doing wrong? or is there a bug in the device which is relevant to our particular arrangement?
Also is there an update to the datasheet that may clarify the SYNC timing requirements? The suggestion (in the response to my previous question) that the SYNC should be synchronous with the rising edge of MCLK is not compatible with the statement on page 15 (of the Rev B datasheet) that SYNC should change synchronous to the falling edge of SCO.
One final question: The delay specified in Table 16, necessary when fewer than 48 coefficients are used: should the delay be before writing the checksum or after?
I would be grateful for any help with this issue.