AnsweredAssumed Answered

ADSP-21489 Open Drain SPI Slave Not Working

Question asked by kenfred on May 21, 2015
Latest reply on Jun 4, 2015 by kenfred



I have multiple ADSP-21489's setup as SPI slaves with a microprocessor as the master. I am attempting to configure the slave SPIs as open drain to prevent MISO contention. However, in all my attempts, I can't get valid data on the MISO line. I'm requesting that someone help me with the correct configuration of the SRU and SPICTL to accomplish this. I have the SPI peripheral mapped to DPI in the default location, but I'm changing some of settings in SPICTL as well as SRU mappings.


I know the hardware, DMA, etc. are working well because things work fine when configured in non-open-drain. To do this, a DSP manually drives MISO output (sets DPI2 pin buffer enable to HIGH) when it is sending data to the master. When it isn't the DSPs turn, it sets the pin buffer enable to LOW to allow another DSP to drive the line. So far bus contention has been avoided because the protocol indicates to the DSP when it's safe to talk. However, I'd like to remove dependence upon the protocol to manage bus arbitration; theoretically the master should be able to coordinate this with the chip-select line..


So I am attempting to enable open drain. The hardware has the requisite pull-ups on the lines. I'm using ADSP-214xx SHARC® Processor Hardware Reference, Revision 1.1 (April 2013). I believe I'm following the manual, but I do have some confusion. On page 10-13, it indicates that the peripheral data signal (SPI_MISO_O) should be sent to the DPI pin buffer enable. However, the figure on the next page shows the peripheral data PBEN_O signal (SPI_MISO_PBEN_O) as the source to the pin buffer enable.  Which is correct? I am assuming that the text is correct and the figure is misleading. My assumption is that enabling open drain inverts the data line, making it suitable to run the pin buffer enable on DPI2. Is that accurate?


I tried it both ways. Here is the first way:

SRU2(LOW, DPI_PB02_I);          // DPI2 input tied low. Open drain mechanism will enable this pin buffer when MISO should be low
SRU2(SPI_MISO_O, DPI_PBEN02_I); // MISO data sent to DPI2 enable. I assume open drain config inverts MISO data
*pSPICTL = 0x6602;              // This is the default SPI config with a few changes.
                                // - Enable MISO (DMISO)
                                // - Enable open drain output (OPD)
                                // - Set word length to 8 (WL)
                                // - MSB first
                                // - CPOL=0 CPHASE=1


When I did this, the MISO line was always high, implying the MISO data line never drove the pin buffer enable. Even if the open drain config isn't inverting the MISO, I would at least expect toggling on the DPI2 output! As an experiment I configured SPI for open drain but tied the DPI2 PBEN high and routed SPI_MISO_O to the pin buffer input. The data was not inverted on the line, so my theory of how the open drain mechanism works is incorrect.


The second way, replacing SPI_MISO_O with SPI_MISO_PBEN_O, also didn't work. The MISO line was always low, implying SPI_MISO_PBEN_O remains high and doesn't have special open drain behavior. I didn't really expect this method to work since the manual says SPI_MISO_PBEN_O is only ever driven in master mode.