Actions
Forum Thread Details
  • State Not Answered
  • Replies 11 replies
  • Subscribers 353 subscribers
  • Views 2256 views
  • Users 0 members are here
Related

PS SPI Pmod JE7 Hardware system

Former Member

Hello everyone,

I'm in the process of interfacing my Avnet CC3000-Pmod Compatible Wi-Fi Adapter to the ZedBoard via the JE7 Pmod header, which is connected to the PS.

At first I thought this should be a simple thing, since creating a hardware system that includes SPI was so simple, but ...

When I try to use the SPI device (via the SpiPs device driver), I am stuck in the XSpiPs_PolledTransfer() function, waiting for the status register flag that indicates the transmission has finished (XSPIPS_IXR_TXOW_MASK). The reason that the flag never comes, is that I read nonsense values from the register (a 0x2 in this case).
Then I added the XSpiPs_SelfTest() function, which failed at the very first register read. So I'm guessing there is something wrong with my hardware design.

I got the Zynq IP setup & configured as follows:

  +--------------------------------+
  |         ZYNQ               DDR +-----> DDR
  |                       FIXED_IO +-----> FIXED_IO
  |                       USBIND_0 +-
-+ TTC0_CLK0_IN         M_AXI_GP0 +-
-+ TTC0_CLK1_IN    TTC0_WAVE0_OUT +-
-+ TTC0_CLK2_IN    TTC0_WAVE1_OUT +-
+-+ M_AXI_GP0_ACLK  TTC0_WAVE2_OUT +-
| |                      FCLK_CLK0 +--+
| |                  FCLK_RESET0_N +- |
| +--------------------------------+  |
+-------------------------------------+

SPI 1: MIO 10 .. 15
SS[1] IO MIO 14
SPI 1 MIO 10 mosi
SPI 1 MIO 11 miso
SPI 1 MIO 12 sclk
SPI 1 MIO 14 ss[1]

The clock is set to ca. 16MHz, which is the maximum the CC3000 can take.

Has anybody had any experience with the CC3000 Adapter, Pmod or SPI on the ZedBoard? I'd be very glad for any help, since I'm pretty much stuck here.

With best regards,
Darius

Parents
  • 0

    Thanks for the link to AR47511. Very interesting. Looks like you're not using the suggested fix of connecting SS0 to EMIO instead of MIO, needed to tie the input side of SS0 to Vcc to prevent unwanted SPI interrupts. I gather you're instead bypassing that connection altogether by using an GPIO, which seems to be a good work around. Yet you're using the rest of the SPI interface. Doesn't that article say you'll still have interrupt reset and hang up problems using the SPI controller as long as that SS0 input isn't tied high (through the EMIO patch)? Do you do that?

    I realized I left out the PWR_EN pin in my table above. So for future reference, I complete it below. From the schematic for the CC3000-Pmod, schematic for the FPGA on the Zedboard,and the MIO's pin definitions,I get the following line assignments:

    CC3000 Pmod pin; JE pin; FPGA pin; MIO Pin using SP1
    SPI_CS ; JE1 ; A6 ; PS_MIO13 ; ss0
    SPI_DI ; JE2 ; G7 ; PS_MIO10 ; mosi
    SPI_DO ; JE3 ; B4 ; PS_MIO11 ; miso
    SPI_CLK ; JE4 ; C5 ; PS_MIO12 ; ck
    SPI_IRQ ; JE7 ; G6 ; PS_MIO0 ; ???
    PWR_EN ; JE10 ; E6 : PS_MIO15; ss2

    I understand you're connecting three of the lines, CS (or SS0), IRQ, and PWR_EN by GPIO routing instead, and mapping those signals back into the SPI controller on the software driver side.

    I suspect that you're getting close. It seems you only have one snag but a lot of other things are working.

    At this point it's trial and error with the system you've got in hand, and not getting stuck into one mode of thinking, and look around other places. One time I had a UART interface I spent a week on debugging, thinking I had a wrong protocol. I finally found a wire was crossed. I had double checked the connection early on, but a tech had also crossed wires in the test cable I used to check! Things like that drive you nuts, but it taught me to don't fixate on one thing. Go back to the beginning and triple check absolutely everything carefully.

Reply
  • 0

    Thanks for the link to AR47511. Very interesting. Looks like you're not using the suggested fix of connecting SS0 to EMIO instead of MIO, needed to tie the input side of SS0 to Vcc to prevent unwanted SPI interrupts. I gather you're instead bypassing that connection altogether by using an GPIO, which seems to be a good work around. Yet you're using the rest of the SPI interface. Doesn't that article say you'll still have interrupt reset and hang up problems using the SPI controller as long as that SS0 input isn't tied high (through the EMIO patch)? Do you do that?

    I realized I left out the PWR_EN pin in my table above. So for future reference, I complete it below. From the schematic for the CC3000-Pmod, schematic for the FPGA on the Zedboard,and the MIO's pin definitions,I get the following line assignments:

    CC3000 Pmod pin; JE pin; FPGA pin; MIO Pin using SP1
    SPI_CS ; JE1 ; A6 ; PS_MIO13 ; ss0
    SPI_DI ; JE2 ; G7 ; PS_MIO10 ; mosi
    SPI_DO ; JE3 ; B4 ; PS_MIO11 ; miso
    SPI_CLK ; JE4 ; C5 ; PS_MIO12 ; ck
    SPI_IRQ ; JE7 ; G6 ; PS_MIO0 ; ???
    PWR_EN ; JE10 ; E6 : PS_MIO15; ss2

    I understand you're connecting three of the lines, CS (or SS0), IRQ, and PWR_EN by GPIO routing instead, and mapping those signals back into the SPI controller on the software driver side.

    I suspect that you're getting close. It seems you only have one snag but a lot of other things are working.

    At this point it's trial and error with the system you've got in hand, and not getting stuck into one mode of thinking, and look around other places. One time I had a UART interface I spent a week on debugging, thinking I had a wrong protocol. I finally found a wire was crossed. I had double checked the connection early on, but a tech had also crossed wires in the test cable I used to check! Things like that drive you nuts, but it taught me to don't fixate on one thing. Go back to the beginning and triple check absolutely everything carefully.

Children
No Data