My project have PIC as master and ADC ADuCM360 as slave and PIC24HJp128310A sends command to ADC via SPI and ADC should reply with 4 bytes of ADC data back at 8Mbps speed. I am not able to achieve this Please help me with this. I am doing this in following way.
ADC keeps polling its one of its digital I/O, and when PIC goes to get data from it, it pulls this pin down and and waits for certain time while ADC accumulated data and puts this in SPITX FIFO(4 byte deep) register, then only pic initiates the Chip select and sends 4 dummy bytes to ADC and expecting 4 valid data in return from its SPI receive buffer one by one without asserting and de-asserting chip select again as i use continuous mode of transfer in ADC. But problem is i am not getting any data back.
I am using keil for ADCuCM 360 c program. Can somebody say whether i am doing correctly, or i am missing something, user guide of ADuCM360 is little confusing to me.
one more question what is meaning of flushing the RX or TX in ADuCM360 paralance.
I can send my program if needed.
Thank you very much I will really appreciate early reply.
The datasheet for the ADC has a table saying:
Table 13. SPI Slave Mode Timing Parameter Description Min Typ Max Unit tCS CS to SCLK edge 62.5 ns tSL SCLK low pulse width1 (SPIDIV + 1) × tUCLK ns tSH SCLK high pulse width1 62.5 (SPIDIV + 1) × tUCLK ns tDAV Data output valid after SCLK edge 49.1 ns tDSU Data input setup time before SCLK edge 20.2 ns tDHD Data input hold time after SCLK edge 10.1 ns tDF Data output fall time 12 35.5 ns tDR Data output rise time 12 35.5 ns tSR SCLK rise time 12 35.5 ns tSF SCLK fall time 12 35.5 ns tDOCS Data output valid after CS edge 25 ns tSFS CS high after SCLK edge 0 ns
with the footnote:
1 tUCLK = 62.5 ns. It corresponds to the internal 16 MHz clock before the clock divider.
Notice SPIDIV - that very much seems like the SPI clock needs to be configured. Note that while the SPI slave takes clocking from the master, the slave side is normally implemented as a state machine that samples the slave-select and clock signal and reacts depending on the level of the signals. And this state machine must be ticked at a high enough clock frequency that it always manages to detect the slave select activation in time to synchronize the transfer when the clock starts to tick. And it must run fast enough that it manages to detect all high and low levels of the SPI clock line.
Next thing - since you can't have zero rise and zero fall times, you can not fulfill Table 13 of the chip datasheet with an 8MHz SPI clock. If you have 10ns rise and 10ns fall times, then the fastest you can run is 10+62.5+10+62.5 ns = 145 ns period which corresponds to 6.9 MHz. If you have 5ns rise and fall times, then you can have a fastest period time of 135ns which means 7.4 MHz. 8 MHz SPI clock will always be outside specifications when the chip runs as SPI slave and the SPI slave is fed the maximum possible 16MHz. And if the 16MHz comes from the internal oscillator, it has -1.8% to +1.4% accuracy which further limits the maximum SPI slave speed possible.
So with a worst-case of the internal oscillator being 1.8% slow, and 10ns rise and 10ns fall times, you get a maximum SPI slave baudrate of 1/(10+10+((62.5*2)/0.982)) GHz = 6.789 MHz. With a 16MHz external crystal oscillator, you can get a bit higher since it has less frequency error. But you also have to factor in the frequency error of the oscillator on the PIC. The PIC oscillator might be on the plus side while the ADC side might be on the minus side.
So somewhere around 4-6 MHz would be a reasonable transfer rate for the SPI communication unless you have very slow rise and fall times.
In the end, it's the chip manufacturer - Analog Devices - who claims that the timing for the high and low parts of the clock signal is exluding the rise and fall times in their SPI slave timing diagram. If you think that diagram is wrong, then you need to contact an Analog Devices support engineer and question their data sheet.
I suggest you modify the Cortex program to feed a counter to the SPI on each request instead of the ADC value. And modify the Pic side to run at a lower frequency.
When it works, then you can start trying to send real ADC data.
Do you have any other means to verify exactly what ADC measurements you get so the ADC isn't floored?
Thank you for the detailed answer, i am learning from you
I will try to do it as you have suggested and get back to you, in the mean time try to get answer from AD as well.
Thanks.