TI E2E Community
Getting SPI1 going with StarterWare
I just got SPI0 working on my BeagleBone with StarterWare (took it out via the channels labeled UART2_RXD, UART2_TXD, I2C1_SDA and I2C1_SCL). I used the examples from the EVM, just removed the profile checks. Now, I'm trying to get SPI1 working as well (I going to try to get DMA running on both of them). What confounds me is that pretty much all the defines I've found are easily changeable from SPI0 to SPI1, by just replacing the text, but as far as I've understood it I need to mux the SPI1 interface as well.
So basically, the functions McSPIPinMuxSetup and McSPI0CSPinMuxSetup (can be seen in mcspi.c in the platform project for EVM) have a bunch of defines that exists only for SPI0, for example CONTROL_CONF_SPI0_CS0. Now my question is, what should I replace these with to get it working with SPI1, or is there something else I'm missing?
PinMux and Module clock configuration support for McSPI Instance 1 was not provided because on EVMAM335x McSPI Instance 0 was connected to SPI-Flash.
To enable pin mux and clock to McSPI Instance 1 these are the changes to be done -
Replace these lines of code(in the platform file)-
/* PinMux for SPI1 CLK */
1) HWREG(SOC_CONTROL_REGS + CONTROL_CONF_SPI0_SCLK) = (CONTROL_CONF_SPI0_SCLK_CONF_SPI0_SCLK_PUTYPESEL | CONTROL_CONF_SPI0_SCLK_CONF_SPI0_SCLK_RXACTIVE);
HWREG(SOC_CONTROL_REGS + CONTROL_CONF_MII1_COL) = 0x32;
/* PinMux for SPI1 D0*/
2) HWREG(SOC_CONTROL_REGS + CONTROL_CONF_SPI0_D0) = (CONTROL_CONF_SPI0_SCLK_CONF_SPI0_SCLK_PUTYPESEL | CONTROL_CONF_SPI0_SCLK_CONF_SPI0_SCLK_RXACTIVE);
HWREG(SOC_CONTROL_REGS + CONTROL_CONF_MII1_CRS) = 0x32;
/* PinMux for SPI1 D1 */
3) HWREG(SOC_CONTROL_REGS + CONTROL_CONF_SPI0_D1) = (CONTROL_CONF_SPI0_SCLK_CONF_SPI0_SCLK_PUTYPESEL | CONTROL_CONF_SPI0_SCLK_CONF_SPI0_SCLK_RXACTIVE);
HWREG(SOC_CONTROL_REGS + CONTROL_CONF_MII1_RXERR) = 0x32;
4) HWREG(SOC_CONTROL_REGS + CONTROL_CONF_SPI0_CS0) = (CONTROL_CONF_SPI0_SCLK_CONF_SPI0_SCLK_PUTYPESEL | CONTROL_CONF_SPI0_SCLK_CONF_SPI0_SCLK_RXACTIVE);
HWREG(SOC_CONTROL_REGS + CONTROL_CONF_RMII1_REFCLK) = 0x32;
0x32 stands for MUXMODE - 2, PullUp/PullDwn Enabled, PullUP Selected, Rx Enabled
5) In McSPI0ModuleClkConfig function replace the below lines of code
HWREG(SOC_CM_PER_REGS + CM_PER_SPI0_CLKCTRL) &= ~CM_PER_SPI0_CLKCTRL_MODULEMODE;
HWREG(SOC_CM_PER_REGS + CM_PER_SPI0_CLKCTRL) |= CM_PER_SPI0_CLKCTRL_MODULEMODE_ENABLE;
while((HWREG(SOC_CM_PER_REGS + CM_PER_SPI0_CLKCTRL) & CM_PER_SPI0_CLKCTRL_MODULEMODE) != CM_PER_SPI0_CLKCTRL_MODULEMODE_ENABLE);
HWREG(SOC_CM_PER_REGS + CM_PER_SPI1_CLKCTRL) &= ~CM_PER_SPI1_CLKCTRL_MODULEMODE;
HWREG(SOC_CM_PER_REGS + CM_PER_SPI1_CLKCTRL) |= CM_PER_SPI1_CLKCTRL_MODULEMODE_ENABLE;
while((HWREG(SOC_CM_PER_REGS + CM_PER_SPI1_CLKCTRL) & CM_PER_SPI1_CLKCTRL_MODULEMODE) != CM_PER_SPI1_CLKCTRL_MODULEMODE_ENABLE);
Also in the McSPI application file replace the macro SOC_SPI_0_REGS with SOC_SPI_1_REGS.
Note: If this post answers your question, please click the Verify Answer button below. Thank you!
Thank you for your reply. Unfortunately it seems that altering the code as you suggested did not result in the interface working. I started looking into what your commands did. Looking at my beaglebone schematics I can see that MCASP0 ACLKX lies on the same pin as SPI1 CLK, so I tried swapping your CONTROL_CONF_MII1_COL with CONTROL_CONF_MCASP0_ACLKX, and the rest of them accordingly. This at least caused the pins to go from low to high when their respective commands were executed according to my logic analyzer.
However, it still seems that the actual transmission will not go through, the pins stay high after their muxing... I'm attaching my files. If you have any possibility to shine some more light on the problem that would be greatly appreciated! Do note that I have not changed function names accordingly, they still claim it's SPI0 even though I modified their contents to SPI1.
Ok, I finally solved it :)
It seemed that the schematics from beaglebone tricked me. I thought the mux setting I was supposed to use was 0x32, but as I zoomed in on the schematics I saw that the SPI stuff had a //, causing the mux settings to need 0x33. And to those who are doing the same thing, pull out the SPI1 via the MCASP0 pins, since those are the ones connected to the correct header on the board.
Thanks for the help Jeethan :)
Great news :)
Anytime for help :)
I am really glade that I found your message about getting SPI1 functional. I am designing a Cape card for the BeagleBone and need to control it from SPI1. I had struggled for several hours/days to get it working. Most of the problem was with StarterWare itself. Those imbedded Libraries should not be allowed and since each project has its own, makes it even more confusing. Anyway, I have my SPI1 now functional thanks to your inputs and messages.
Good to hear I'm not the only one who had troubles getting it to work, I'm glad my posts could be of assistance Larry :)
I did have one other problem, The MOSI & MISO default were backwards. I added the command McSPIDataPinDirectionConfig to reverse them. When i looked at schematic, I saw SP1_D0 and SPI_D1. i assumed that that was a DO & DI, its not. Its really is D0(zero) &D1(one). I then found in the AM335 data sheet that they can be made as an input or output and there is a command to reverse them.
I have a question that is related:
Why are all the pins set up with the RXACTIVE field set as "1 = receiver enabled"?
The SPI clock pin, chip select pin and MOSI pin are outputs so I'd expect these to have the RXACTIVE field set as "0 = receiver disabled". I've tried using this set up and it didn't work, I'd just like to understand why.
As per my understanding the internal SPI clock is sourced through the output buffer to the AM335x IO pad and looped back into the device through the input buffer. This is done so the internal SPI logic operates with a clock that has similar timing as the SPI device. Otherwise the AM335x output buffer delay would cause the internal SPI clock to appear several ns early relative to the other SPI signals.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.