Post Go back to editing

ADSP-21479, SPORT with PCG, ADC reading

Hi

I am trying to use the SPORT with PCG to control and read ADC. I set the PCG as the SPORT clock and FS, and they work as I set, and I can see the ADC sending out data at the SO line. But when I read it through the SPORT, I found the data not correct.

In my code writen by C, I still use the method of polling the receive buffer status (I am trying to use interrupt way, but that needs some time to me). And I read the data line three times and put them in DM for checking in the code. For easy to check the timing of the reading, I use a DAI port to set a pulse once I read the data line.

Following is the timing of reading the three data.

In the diagram, the blue trace is 12-bit ADC output(the value is AD5 or AD6), the green trace is ADC clock, the yellow tarce is the ADC's converter control (FS), the purpul one is the pulse I issued after read a data.

You can see in the diagram that the reading time is not correct (except the first one), and the three read data in the memory were:0x00000D50, 0x00000000, and 0x0000000.

Maybe the configuration for the SPORT with PCG not correct in the code, but I can't figure out where it is.

Would you please check it for me?

Attached is the code for your consideration.

Thanks a lot,

Ning

SPORT-PCG-ADC-Test1.c.zip
  • Hi Ning,

    I looked at your code. Based on that, I have following suggestions and questions:

    1) You mentioned that you are using PCG to generate clock and frame sync for the SPORT and the ADC. But, I see that you have set the bits ICLK and IFS in the SPCTL1 register. You might need to clear these bits in case you want to use external (PCG) clock and frame sync signals. Also, in the waveform, I see that the clock is gated (with pause in between). Could you please clarify if this clock is being generated by the PCG or by the ADC itself?

    2) Please also note that, it's not a good idea to read the RX buffer without making sure that it's full. So, please remove the initial dummy read from your code where you don't poll for the FIFO status bits.

    Thanks,

    Mitesh

  • Hi Mitesh,

    Thank you very much for your suggestion.

    I cleared the ICLK and IFS of the SPCTL1 in the code and ran it. The result are still not correct. Below are the three reading ADC values put into the memory started from 0B3000. None of the three values is the same with the real ADC output (0xAD5 or 0xAD6).

    https://ez.analog.com/cfs-file/__key/communityserver-discussions-components-files/397/379bb6461aab4192cd7960e5181d1885.html

    The the ADSP-214XX SHARC Processor Hardware Reference. I could not find that how to configure the SPCTLx when apply PCG. That's why I am not confident with the configuration of the SPCTL1 in my code when I try to the PCG as the SPORT clock and FS.

    Attached is my updated code that got the result above. Would you please check it for me?

    Should you need other file about the testing, please also let me know.

    Thanks,

    Ning

    SPORT-PCG-ADC-Test1.c.zip
  • Sorry, Mitesh.

    I pasted the DM map pirture in last post, but it's lost when posted.

    Now I pasted it again. It seems to small. Hope you could read it.

    Thanks,

    Ning

  • Hi Ning,

    Before I look into your code, could you please clarify why there are pauses in the SCLK signal in the picture you posted in previous post ? Generating this sort of signal is not directly possible by using PCG. So, I am curious to know if the CLK signal which is shown in the picture is the PCG output or coming from the ADC. Could you pelase clarify?

    Thanks,

    Mitesh

  • Hi Mitesh,

    Thanks for your response.

    Yes, I am sure the Sclock and FS are generated by the PCG. I first set up the PCG and viewed the generated signals and then I connected the ADC card to the developing board.

    I found something new and I am checking it, and I'll post my test result soon.

    Thanks again,

    Ning

  • Hi Mitesh,

    After some tests for the configuration of SPCTL Register, I can read the ADC data corrctly now.

    The final setting for register is: FS_BOTH | LAFS | LFS | FSR | CKRE | SLEN12 | SPEN_A.

    Besides, I also tried to use SPORT0 and PCGC for writing to a DAC (16-bit and two addr bits required). It works. But I found that once I write the first data, the SPORT keeps transmitting the same data continually with the FS frequency until I update the date, and the new data is kept transmitting. Does it make sense?

    I set the SPORT0 as: SRTRAN | LAFS |LFS | FSR | CKRE | SLEN18 | SPEN_A.

    Thanks,

    Ning

  • Hi Ning,

    Glad to know that your issue is solved. Yes, the SPORT will keep sending the last data if there is a valid frame sync and the TX buffer is not loaded with a new data. I am not sure why are you setting the FS_BOTH bit as this is required only when both the channles A and B are enabled.

    Thanks,

    Mitesh

  • Hi Mitesh,

    I set the FS_BOTH because I'll use two ADCs (Left and Right) with the signal SPORT later.

    I just got another question about the FS Phase that seems weird to to my. In my code, I want to read a ADC data (per SPORT1 with PCGA) and then send the data to a DAC (per SPORT0 with PCGC).

    For getting shortest latency, I need to adjust the phase between FSA and FSC (I use FSA to synchronize FSC (Per PCG_SYNC_CLKC_I).

    When I adisuted the FSAPHASE and FSCPHASE, I found FSAPHASE worked as I set, but FSCPHASE couldn't make FSC moved against FSA. (In fact the FSCPHASE used to work when I adjusted the SCLKC with FSC.) I don't know what's wrong with PCGC configuration in my code. I tried the code for two developing boards, and got the same result.

    Would please check the attached code for me?

    Thanks a lot,

    Ning

    SPORT-PCG-ADC-Test4.c.zip
  • Hi Mitesh,

    I found out the reason of the problem.  I set the value of FSCPHASE that was larger than the FSCDIV.

    Thank you and Merry Christmas,

    Ning

  • Hi Ning,

    Thanks for the wishes and glad to know that your issue is resolved. Please let me know in case you have any further questions.

    Regards,

    Mitesh