Other Parts Discussed in Thread: ADS8548
I have run into a significant problem with our DSP 28346 hooking up to an external ADC. I have run out of ideas and I am hoping that you or someone at TI would be able to provide help or a quick fix for me. I have exhausted most of my own resources, and I am now blocked by this problem.
First, let me describe what I have set up and how it works. We have a DSP 28346 connected to an ADC (TI ADS8548). The ADC has 2 SPI ports that are connected to the 2 McBSP ports of the 28346. The McBSP ports are running in SPI mode to be compatible with the ADC. I am using the DMA on the 28346 to collect the data from the ADC and transfer the values to memory that the DSP can use. Simple enough.
The ADC will get a start of conversion from the DSP and will perform a conversion on the 8 input values fed into it. The ADC will then signal back to the DSP that the conversion is complete. The DMA then provides clock and chip select to the ADC which causes the values to move from the ADC to the DSP. The 2 ports on the ADC are in SPI slave mode. The DSP uses port A as the SPI master to provide clock and chip select to the slaves, and port B on the DSP is also set up as a SPI slave so that it too will use the same clock and chip select that is provided by port A. This allows the data transfer to occur simultaneously on both ports.
The ADC transfers a total of 8 words to the DSP during a given transfer. Since we are using 2 ports, 4 values will come over port A, and the remaining 4 values will come over port B. (Port A gets ADC channels A0,A1,C0,C1 and Port B gets ADC channels B0,B1,D0,D1 as described in the ADC data sheet).
We are now at the point where things are operating correctly – except for one major problem! It is this problem that I need your help with.
When these values come across from the ADC, I see that the values on Port A (SPI Master) are coming over properly – they look fine and they correspond to what we see on the scope. However, the values that I receive on Port B (SPI slave) are all left shifted by 1 bit! This effectively is doubling the values and losing the MSB!
My question is how this is possible? I have included the routine I am using to configure the McBSP ports – it is set to configure as either a master or a slave. I cannot see how it could work for the A port but not for the B port when they are both using the same configurations, clocks, and chip selects! I have them configured for high inactive state with delay (3,1,1 CLKSTP, CLKXP, CLKRP). (I am using the McBSP manual SPRUG80A to configure the McBSP ports). This mode says that it should transmit ½ cycle ahead of the falling edge, and receive on the falling edge. I am attaching a bunch of screen captures from the scope to help illustrate my questions. The first screen capture I would like to refer to is called “delay-mode-a-good-b-bad-2.jpg”. In all of these captures, the yellow signal is clock, the green signal is the data line on McBSP port B, the blue signal (at the bottom) is chip select, and the pink signal is data on McBSP Port A. In this capture, you can see that the scope picks up port A as a 7, and port B as a 2 for the first word of the transfer. What I am seeing come in from the DMA is a 7 on port A (correct), but a 5 on port B (incorrect)! If you count falling edges on the clock, there is no way you can get a 5. It is only if you ignore a clock pulse entirely, or if you are clocking on rising edges. However, I am sure I have the McBSP ports both set to clock on the falling edges – I have even checked the McBSP registers during the run to confirm these settings.
Next, I figured that what I would like to try is the low inactive without delay mode (2,0,0 CLKSTP, CLKXP, CLKRP). However, when I set the ports to this mode, I see the strange behavior where the 16th clock pulse is held for some extra time, and in the last word, only 15 clock pulses are issued. The result is 3 received words that are mangled and an incomplete 4th word. See the capture entitled “no-delay-mode-missing-bit.jpg”. This does not seem like it is working properly. If it was working, I would imagine this is the mode that I would like to use if the delay mode doesn't work.
I have tried the other 2 modes mentioned in the manual, but neither of them work any better. The “high inactive state without delay” (2,1,0) has the similar missing bit problem, whereas the “low inactive state with delay” (3,0,1) never seems to pass data to the McBSP ports at all!
I am also attaching a third capture that shows a complete 4 word transmission from the 2 ports where the A port data is received properly, and the B port data running with the same configuration (3,1,1), clock and chip select but is shifted left by 1 bit. This capture is called “delay-mode-2-ports.jpg”. It seems to me that if it works for port A, it ought to work for port B as well. I cannot understand how it is broken for 1 port but works for the other. The data that the McBSP reports on port A for the following signal is correctly reported as 0x0007,0xFFFE,0xFFFF,0xFFFF. However, the data that is recieved by port B during the same time is incorrectly reported as: 0x0005,0xFFFF,0xFFFD,0xFFFC
Last but not least is a capture that illustrates this problem very plainly and easily. This is a capture of the first full 16 bit word transmitted from the ADC to the DSP. The port is configured to receive on the falling edge as usual. The scope picks this up as a 1, but the McBSP reports it as a 3. If you go through and count the falling edges in this picture, there is no way this could be construed as a 3. It is only a 3 if you use 17 clock pulses for a word counting the falling edges, or if you skip the first clock altogether. The only other possibility is that even though the port is configured to receive on the falling edge, it is actually receiving on the rising edge. The name of this capture is “how-is-this-a-3.jpg”
I am attaching all of these scope captures for your review as well as my configuration for the DSP McBSP ports – A is a master, B is a slave. If there is any other information you would like, please just let me know and I will be happy to assist.
As I said, I am sort of blocked on this because the received data is corrupted so I cannot move past this until I figure out how to correct it. Any help, suggestions, or fixes would be most appreciated!
Thanks!
-Jeff
